[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
> On updating to latest Auctex from the Package Manager, there were > hundreds of warnings during compilation. Indeed. > Expected behaviour: > Packages in Elpa compile without warnings. ELPA packages are not magical that way, no. It completely depends on the package's maintainers to try and make their code "warning-free", and even if they do that, it's difficult to make sure it's warning-free under all Emacs versions (some maintainers insist on warning-freeness to the point of disabling warnings or obfuscating code, which I find to be both very bad ideas). For GNU ELPA packages, I occasionally try to address some of those warnings. In the case of AUCTeX, I haven't tackled that job yet. Stefan ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Stefan Monnier writes: Hi Neil & Stefan, >> On updating to latest Auctex from the Package Manager, there were >> hundreds of warnings during compilation. > > Indeed. Oh, yes. Hm, compiling AUCTeX from its Git sources issues just one warning (and a few more in preview). With the ELPA package, there're much more of them... Ah, ok, AUCTeX has an lpath.el that disables byte-compile warnings. Now I also get pages over pages of warnings. Most of them are references to free variables and unknown functions from style files. But the style files can't be used without AUCTeX being loaded anyway, so at runtime the vars/functions will be defined. Any good idea to fix those? I could add requires, but that would possibly slow down the compilation and is not neccessary as explained above. I could add defvars (but no declare-functions cause that's not available on older emacsen/xemacs) for the free variables, but again that's not really neccessary. I could change AUCTeX' build process so that free-vars and unresolved warnings are ignored for the style files, but that won't affect the ELPA builds... >> Expected behaviour: >> Packages in Elpa compile without warnings. > > ELPA packages are not magical that way, no. It completely depends on > the package's maintainers to try and make their code "warning-free", > and even if they do that, it's difficult to make sure it's > warning-free under all Emacs versions (some maintainers insist on > warning-freeness to the point of disabling warnings or obfuscating > code, which I find to be both very bad ideas). AUCTeX tries to be compatible with Emacs 21.4+ and even XEmacs 21.4+, so changing code just for eliminating some warning is hard because is requires quite some testing effort to check all supported emacsen in all supported versions (or at least the oldest and the newest). > For GNU ELPA packages, I occasionally try to address some of those > warnings. In the case of AUCTeX, I haven't tackled that job yet. Now that I know that there are warnings, I'll tackle those that can be addressed in a meaningful manner myself. Bye, Tassilo ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Tassilo Horn writes: > Any good idea to fix those? I could add requires, but that would > possibly slow down the compilation and is not neccessary as explained > above. I could add defvars (but no declare-functions cause that's not > available on older emacsen/xemacs) for the free variables, but again > that's not really neccessary. I could change AUCTeX' build process so > that free-vars and unresolved warnings are ignored for the style files, > but that won't affect the ELPA builds... In Org we use compatibility macros, mostly using the org namespace, but in a few cases simply addign a missing definition. More specifically for declare-function: (eval-and-compile (unless (fboundp 'declare-function) (defmacro declare-function (fn file &optional arglist fileonly) `(autoload ',fn ,file Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Glenn Morris writes: > Tassilo Horn wrote: > >> (but no declare-functions cause that's not available on older >> emacsen/xemacs) > > It's available since Emacs 22.2, ie 6 years, or the past 9 Emacs releases. > If XEmacs has not added even a compat stub in that time, which would > take about a minute, that seems telling. While you are at it, I had often complaints about some completing-read's working badly with helm. This is because they are not written correctly in Auctex. I have submitted a bug long time ago but never had an answer. If you are interested to fix this you can have a look here: https://github.com/thierryvolpiatto/auctex -- Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Tassilo Horn wrote: > (but no declare-functions cause that's not available on older > emacsen/xemacs) It's available since Emacs 22.2, ie 6 years, or the past 9 Emacs releases. If XEmacs has not added even a compat stub in that time, which would take about a minute, that seems telling. ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Glenn Morris writes: >> (but no declare-functions cause that's not available on older >> emacsen/xemacs) > > It's available since Emacs 22.2, ie 6 years, or the past 9 Emacs releases. > If XEmacs has not added even a compat stub in that time, which would > take about a minute, that seems telling. I've just checked XEmacs 21.5_beta33, and no, it's not there. And it wouldn't matter much since AUCTeX tries to support at least the latest released XEmacs version which is 21.4. (Actually, I'm not really trying hard to achieve that actively, but I try not to break that support carelessly.) Bye, Tassilo ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
> (eval-and-compile > (unless (fboundp 'declare-function) > (defmacro declare-function (fn file &optional arglist fileonly) > `(autoload ',fn ,file Yuck! This is an ugly trick trying to silence warnings. Better macroexpand it to nil: you'll get warnings in older Emacsen, but at least you won't end up changing the code's behavior. Stefan ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Stefan Monnier writes: >> (eval-and-compile >> (unless (fboundp 'declare-function) >> (defmacro declare-function (fn file &optional arglist fileonly) >> `(autoload ',fn ,file > > Yuck! This is an ugly trick trying to silence warnings. Not much uglier than declare-function itself. These things would perhaps benefit if one could declare-require the source file in question (it's almost invariably callbacks and guarded calls into external packages that end up needing this treatment), but that still doesn't address how to make it backward compatible. > Better macroexpand it to nil: you'll get warnings in older Emacsen, but > at least you won't end up changing the code's behavior. That's certainly not recommended for everyone and everything, but since declare-function must used in situations were the function to be declared is known to be already defined at runtime, the autoload will never do anything anyway; if it does it was a bug to begin with. Defining this nil and then not finding the one warning that must be dealt with in the hundreds of spurious warnings is decidedly worse. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
> That's certainly not recommended for everyone and everything, but since > declare-function must used in situations were the function to be > declared is known to be already defined at runtime, the autoload will > never do anything anyway; It does do something: - it does something during byte-compilation. - it does something during run-time if the function is "already loaded when you call it" but not "already loaded when you load the file". Both of those situations are quite common. The reason why you don't suffer from it is not that the autoload doesn't do anything, but because the autoload is usually harmless. > Defining this nil and then not finding the one warning that must be > dealt with in the hundreds of spurious warnings is decidedly worse. Admittedly I haven't spent much time dealing with compatibility with older Emacsen lately, but in the past I've never found warnings useful for that work. So I only ever used warnings to help debug & improve my code on my "main" Emacs version, and completely ignored warnings when porting to older Emacsen (relying on testing and bug-reports instead). Of course, it's probably got to do with taste, but if you're going to use `autoload', then I strongly suggest you name it `-declare-function', since when "adding a missing definition" you're better off defining it *exactly* like a recentish Emacs. Stefan ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Stefan Monnier writes: >> That's certainly not recommended for everyone and everything, but since >> declare-function must used in situations were the function to be >> declared is known to be already defined at runtime, the autoload will >> never do anything anyway; > > It does do something: > - it does something during byte-compilation. That's the intended effect. I haven't checked if it could in fact skip the compile part of eval-and-compile; if so, that would be an obvious improvement. > - it does something during run-time if the function is "already loaded > when you call it" but not "already loaded when you load the file". Which is not supposed to happen in these cases, otherwise you'd be able to use a plain require. > Both of those situations are quite common. The reason why you don't > suffer from it is not that the autoload doesn't do anything, but because > the autoload is usually harmless. That too. >> Defining this nil and then not finding the one warning that must be >> dealt with in the hundreds of spurious warnings is decidedly worse. > > Admittedly I haven't spent much time dealing with compatibility with > older Emacsen lately, but in the past I've never found warnings useful > for that work. So I only ever used warnings to help debug & improve my > code on my "main" Emacs version, and completely ignored warnings when > porting to older Emacsen (relying on testing and bug-reports instead). I can't speak for other eLisp libraries, but testing came late for Org and test coverage isn't quite up where it would need to be for this to work. Besides, testing on older Emacsen gets rather difficult since they don't compile on my system any more and I'd need to set up a container or VM. > Of course, it's probably got to do with taste, but if you're going to > use `autoload', then I strongly suggest you name it > `-declare-function', since when "adding a missing definition" you're > better off defining it *exactly* like a recentish Emacs. Moving it to Org namespace may be in the cards given that Org already does that for most other compatibility macros. If you know a way to have it really just declare the function without byte-compiler magic let me know. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
>> Admittedly I haven't spent much time dealing with compatibility with >> older Emacsen lately, but in the past I've never found warnings useful >> for that work. So I only ever used warnings to help debug & improve my >> code on my "main" Emacs version, and completely ignored warnings when >> porting to older Emacsen (relying on testing and bug-reports instead). > I can't speak for other eLisp libraries, but testing came late for Org > and test coverage isn't quite up where it would need to be for this to > work. By testing I meant "start up an old Emacs and try to play a bit with the feature see if it seems to work". Of course, if you have a test suite scripted up and all, that's even better. > Besides, testing on older Emacsen gets rather difficult since they > don't compile on my system any more and I'd need to set up a container > or VM. "dpkg" was able to install emacs19, emacs20, emacs21, emacs22, emacs23, emacs24 on my machines, so I haven't had to build them by hand. Stefan ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Thierry Volpiatto writes: Hi Thierry, > While you are at it, I had often complaints about some completing-read's > working badly with helm. > This is because they are not written correctly in Auctex. > I have submitted a bug long time ago but never had an answer. Oh, sorry, I must have missed it. > If you are interested to fix this you can have a look here: > > https://github.com/thierryvolpiatto/auctex Fixed, thanks! Bye, Tassilo ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Tassilo Horn wrote: > ;; Local Variables: > ;; byte-compile-warnings: (free-vars unresolved) > ;; End: > > That does indeed stop the unresolved function warnings but not the > free-vars warnings. Why not? Personally I think this is bad practice. Anyway, aren't you missing a "not": byte-compile-warnings: (not free-vars unresolved) ? Note that this only works since Emacs 23.1. In older Emacs it will at best have precisely the opposite effect to the one you intend. ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Tassilo Horn writes: > Thierry Volpiatto writes: > > Hi Thierry, > >> While you are at it, I had often complaints about some completing-read's >> working badly with helm. >> This is because they are not written correctly in Auctex. >> I have submitted a bug long time ago but never had an answer. > > Oh, sorry, I must have missed it. > >> If you are interested to fix this you can have a look here: >> >> https://github.com/thierryvolpiatto/auctex > > Fixed, thanks! Great! I will remove my branch. > Bye, > Tassilo -- Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Glenn Morris writes: Hi Glenn, >> ;; Local Variables: >> ;; byte-compile-warnings: (free-vars unresolved) >> ;; End: >> >> That does indeed stop the unresolved function warnings but not the >> free-vars warnings. Why not? > > Personally I think this is bad practice. Why? As said, all those style files use LaTeX-* and TeX-* vars and functions defined by AUCTeX's core. However, the style files can't be required individually, but AUCTeX itself loads them dynamically depending on the \usepackages and \documentclass you use in your LaTeX document. And then it's evident that those vars/functions are defined. > Anyway, aren't you missing a "not": > >byte-compile-warnings: (not free-vars unresolved) > > ? Arg, indeed. :-) > Note that this only works since Emacs 23.1. In older Emacs it will at > best have precisely the opposite effect to the one you intend. Well, AUCTeX releases have a (setq byte-compile-warnings nil) in a custom lpath.el that's used when byte-compiling anyway. My intent is only to get rid of warnings that are actually ok just for the ELPA builds. Bye, Tassilo ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Tassilo Horn wrote: >> Personally I think this is bad practice. > > Why? Well, what if you make a typo and use a function that is really undefined? > As said, all those style files use LaTeX-* and TeX-* vars and > functions defined by AUCTeX's core. However, the style files can't be > required individually, but AUCTeX itself loads them dynamically > depending on the \usepackages and \documentclass you use in your LaTeX > document. Why can't the style files require whatever AUCTeX files they need? > Well, AUCTeX releases have a (setq byte-compile-warnings nil) in a > custom lpath.el that's used when byte-compiling anyway. Which makes this whole exercise rather laughable, doesn't it? "All releases must ship with no warnings." "Job done!" ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Glenn Morris writes:
>>> Personally I think this is bad practice.
>>
>> Why?
>
> Well, what if you make a typo and use a function that is really
> undefined?
It'll throw at runtime, but hopefully it does so before shipping a
release.
>> As said, all those style files use LaTeX-* and TeX-* vars and
>> functions defined by AUCTeX's core. However, the style files can't
>> be required individually, but AUCTeX itself loads them dynamically
>> depending on the \usepackages and \documentclass you use in your
>> LaTeX document.
>
> Why can't the style files require whatever AUCTeX files they need?
They could, I guess. However, style files should be easy to write for
non-elisp experts. They usually are nothing more than:
--8<---cut here---start->8---
(TeX-add-style-hook
""
(lambda ()
(TeX-add-symbols
'("" 1) ;has one arg
'("" 2 ;has two args
--8<---cut here---end--->8---
So that would need a (require 'tex), if it would also define latex
environments, it'll need (require 'latex) too, and if it'd also fiddles
with font-locking, it'll also (require 'font-latex). I mean, we could
document in the manual section about writing custom style files which
AUCTeX files need to be required when using which function. But style
files are usually written in parallel to working on/testing with a
sample tex document using the corresponding LaTeX style, so then the
functions/vars are defined anyway and one can just TAB your way through.
Another thing is that the style files reside in a subdirectory, so to
make the requires working their compilation would need a different
load-path. (No big thing for the regular Makefile build job, but I'm
not sure about ELPA...)
And possibly adding requires would slow down the compilation process
quite a bit. There are currently 144 style files. As said, most of
them are rather short, but the tex, latex, and font-latex they'd need to
require are large (~14000 LOC in total).
>> Well, AUCTeX releases have a (setq byte-compile-warnings nil) in a
>> custom lpath.el that's used when byte-compiling anyway.
>
> Which makes this whole exercise rather laughable, doesn't it?
Kinda. I didn't notice that before this bug report, too. And I'll to
address the relevant warnings and remove that config.
> "All releases must ship with no warnings."
>
> "Job done!"
vc-annotate says:
73660122 (Per Abrahamsen 1996-08-29 20:32:16 + 6)
Good job, Per! And it lasted for almost 18 years now. ;-)
Bye,
Tassilo
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
2014-01-30 Tassilo Horn : > And possibly adding requires would slow down the compilation process > quite a bit. There are currently 144 style files. As said, most of > them are rather short, but the tex, latex, and font-latex they'd need to > require are large (~14000 LOC in total). Is it possible to load `tex.el', `latex.el', and `font-latex.el' just once through command line before compiling all style files instead of adding a `require' in each file? Bye, Mosè ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Tassilo Horn writes: >> Why can't the style files require whatever AUCTeX files they need? > > They could, I guess. I was wrong. I've just added the needed requires to all style files, but I get exactly as many warnings as before. This is because of these reasons. 1. Many TeX-* and LaTeX-* functions and variables are not generated before tex.el and latex.el are loaded. AUCTeX has an auto parser facility that generates a parser for some kind of LaTeX thingy. Typical "thingies" in LaTeX are symbols/macros, environments, lengths, counters, or labels. For each such thingy, functions and variables named TeX-thingy-* or LaTeX-thingy-* are generated. E.g., tex.el itself does (TeX-auto-add-type "symbol" "TeX") which generates functions/vars TeX-symbol-list, TeX-symbol-list-filtered, TeX-symbol-changed, etc. (And the same for 10 other thingies.) The byte-compiler doesn't seem to execute top-level funcalls, so all those functions/vars are unknown at compile-time. 2. The AUCTeX's auto parser is open to be used for style-files, too. For example, style/acronym.el does (TeX-auto-add-type "acronym" "LaTeX") which when evaluated creates LaTeX-acronym-list, etc. Again, those are unknown to the byte-compiler. I guess I should wrap those TeX-auto-add-type calls with a `eval-when-compile', right? 3. How should one deal with code like this? (when (featurep 'font-latex) (font-latex-add-keywords ...)) 4. Or with code like this? (defun foo () (require 'url-util) (url-util-* ...)) Thanks, Tassilo ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Mosè Giordano writes: >> And possibly adding requires would slow down the compilation process >> quite a bit. There are currently 144 style files. As said, most of >> them are rather short, but the tex, latex, and font-latex they'd need >> to require are large (~14000 LOC in total). > > Is it possible to load `tex.el', `latex.el', and `font-latex.el' just > once through command line before compiling all style files instead of > adding a `require' in each file? Our Makefile does just one emacs -f batch-byte-compile call passing all *.el files as arguments, so even with many requires, each file will be parsed only once. And with the ELPA builds, I think it's the same thing. So my argument is not substantial. Bye, Tassilo ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
> And with the ELPA builds, I think it's the same thing. IIRC there are different cases. When installing an ELPA package, indeed all the .el files are compiled within the running Emacs. There aren't many guarantees of ordering tho, so it could potentially happen that the style files get compiled before loading tex.el. When installing the whole GNU ELPA branch via "git clone .../elpa; make", then each file is compiled individually in a separate Emacs process. But IIRC only the files in the top-level directory of each package are byte-compiled in that case, so the style files won't be byte-compiled at all. Stefan ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
> 1. Many TeX-* and LaTeX-* functions and variables are not generated >before tex.el and latex.el are loaded. AUCTeX has an auto parser [...] >The byte-compiler doesn't seem to execute top-level funcalls, so all >those functions/vars are unknown at compile-time. Indeed, the byte-compiler compiles the code, rather than executes it. But if it sees a (require 'foo) it will run that (require 'foo), i.e. it will load foo.el(c), which executes all of the code in there. So a (require 'tex) will execute (TeX-auto-add-type "symbol" "TeX") at compile-time, and will hence cause TeX-symbol-list to exist at compile-time. > (TeX-auto-add-type "acronym" "LaTeX") [...] > I guess I should wrap those TeX-auto-add-type calls with a > `eval-when-compile', right? You could. Or you could turn them into macros. > 3. How should one deal with code like this? > (when (featurep 'font-latex) > (font-latex-add-keywords ...)) (when (fboundp 'font-latex-add-keywords) (font-latex-add-keywords ...)) > 4. Or with code like this? > > (defun foo () > (require 'url-util) > (url-util-* ...)) Good question. We usually use `declare-function' for these, but admittedly, it's not a great solution. Stefan ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Stefan Monnier writes: >> And with the ELPA builds, I think it's the same thing. > > IIRC there are different cases. > > When installing an ELPA package, indeed all the .el files are compiled > within the running Emacs. There aren't many guarantees of ordering > tho, so it could potentially happen that the style files get compiled > before loading tex.el. Ok, I see. > When installing the whole GNU ELPA branch via "git clone .../elpa; > make", then each file is compiled individually in a separate Emacs > process. But IIRC only the files in the top-level directory of each > package are byte-compiled in that case, so the style files won't be > byte-compiled at all. That's ok. But if the style files were compiled, adding the requires into the style files would make the compilation take minutes, because each style file compilation would need to load the core files first. Bye, Tassilo ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Stefan Monnier writes: >> 1. Many TeX-* and LaTeX-* functions and variables are not generated >>before tex.el and latex.el are loaded. AUCTeX has an auto parser > [...] >>The byte-compiler doesn't seem to execute top-level funcalls, so all >>those functions/vars are unknown at compile-time. > > Indeed, the byte-compiler compiles the code, rather than executes it. > > But if it sees a (require 'foo) it will run that (require 'foo), > i.e. it will load foo.el(c), which executes all of the code in there. > So a (require 'tex) will execute (TeX-auto-add-type "symbol" "TeX") at > compile-time, and will hence cause TeX-symbol-list to exist at > compile-time. Ah, ok, but that doesn't help when foo.el does (TeX-auto-add-type "foo" "TeX") and uses the generated functions itself, like it's done by tex.el, latex.el, and all style files that define their own auto parsers. Concretely, I still get warnings if tex.el uses (TeX-symbol-list) generated by (TeX-auto-add-type "symbol" "TeX"), but if latex uses the same function, it's ok for the compiler. >> (TeX-auto-add-type "acronym" "LaTeX") > [...] >> I guess I should wrap those TeX-auto-add-type calls with a >> `eval-when-compile', right? > > You could. No, I get a compile error in tex.el when compiling (defun TeX-auto-add-type (...) ...) ... (eval-when-compile (TeX-auto-add-type "symbol" "TeX")) because then TeX-auto-add-type is not known at compile-time. So then I'd need to wrap the defun, too, and also the function and variables that are used in TeX-auto-add-type. That doesn't seem manageable... And if I wrap, e.g., the (TeX-auto-add-type "environment" "LaTeX") with eval-with-compile, it compiles fine (cause it's in latex.el which requires tex.el) and I get rid of some free-vars and unresolved warnings, but then I get an error when finding a latex document. Debugger entered--Lisp error: (void-function LaTeX-add-environments-auto) Wrapping with (eval-when (compile load eval) ...) seems to work, but I'm not sure if that's a good idea. > Or you could turn them into macros. Indeed, that looks like a typical use-case for macros, but I'm rather sure that there's a good reason that the auto parser stuff is like it is. David? >> 3. How should one deal with code like this? >> (when (featurep 'font-latex) >> (font-latex-add-keywords ...)) > > (when (fboundp 'font-latex-add-keywords) > (font-latex-add-keywords ...)) While we are at it: David, is there any reason why somebody would want to set TeX-install-font-lock to 'ignore nowadays so that font-latex is not loaded? If not, I'm tempted to remove the variable, require font-latex in tex.el, and get rid of all those boundness checks in the styles. >> 4. Or with code like this? >> >> (defun foo () >> (require 'url-util) >> (url-util-* ...)) > > Good question. We usually use `declare-function' for these, but > admittedly, it's not a great solution. I see. The reason for the code above is that foo is only callable in very special conditions. Concretely, there're some functions that are only used with recent GNU emacs version with dbus support and the user using Evince as pdf viewer. Bye, Tassilo ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Tassilo Horn writes: > Wrapping with (eval-when (compile load eval) ...) seems to work, but I'm > not sure if that's a good idea. > >> Or you could turn them into macros. > > Indeed, that looks like a typical use-case for macros, but I'm rather > sure that there's a good reason that the auto parser stuff is like it > is. David? Sorry to disappoint you here, but that stuff was there well before me and I've not messed with it to any noticeable degree. I seem to remember that Reiner Steib might have done a bit more in that respect, but I might be mixing up names here, too. At any rate, the base of the style code has probably not been touched for something like 20 years, so it's quite likely that the reasons for making any particular technical decision in that area are decidedly historical. > While we are at it: David, is there any reason why somebody would want > to set TeX-install-font-lock to 'ignore nowadays so that font-latex is > not loaded? font-latex has different font highlighting from the Emacs default modes, and some may prefer the latter (which also tends to track Emacs' current capabilities better and might be more efficient for that reason). -- David Kastrup ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
David Kastrup writes: >>> Or you could turn them into macros. >> >> Indeed, that looks like a typical use-case for macros, but I'm rather >> sure that there's a good reason that the auto parser stuff is like it >> is. David? > > [...] > At any rate, the base of the style code has probably not been touched > for something like 20 years, so it's quite likely that the reasons for > making any particular technical decision in that area are decidedly > historical. Ok. I've now turned TeX-auto-add-type into a macro and it seems to work. And it also uncovered a bug where the lambda added to TeX-remove-style-hook contained (setq "[La]TeX--list" nil), i.e., there's a string rather a symbol. I'll have to do some more testing before merging my local branch into master and pushing, though. >> While we are at it: David, is there any reason why somebody would >> want to set TeX-install-font-lock to 'ignore nowadays so that >> font-latex is not loaded? > > font-latex has different font highlighting from the Emacs default > modes, and some may prefer the latter (which also tends to track > Emacs' current capabilities better and might be more efficient for > that reason). Ok, thanks. Bye, Tassilo ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
> That's ok. But if the style files were compiled, adding the requires > into the style files would make the compilation take minutes, because > each style file compilation would need to load the core files first. Yup. I personally don't see much need to add the `require's in those style files. Then again, I'm not too bothered by lingering warnings. Stefan ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
>>> I guess I should wrap those TeX-auto-add-type calls with a >>> `eval-when-compile', right? >> You could. > No, I get a compile error in tex.el when compiling Of course, eval-when-compile and eval-and-compile come with their own set of problems. My "you could" wasn't really meant as an encouragement. >> Or you could turn them into macros. > Indeed, that looks like a typical use-case for macros, but I'm rather > sure that there's a good reason that the auto parser stuff is like it > is. David? Whatever the reason, looking at the code of TeX-auto-add-type, I think it *really* should be turned into a macro, and use defvar/defalias instead of set/fset. > While we are at it: David, is there any reason why somebody would want > to set TeX-install-font-lock to 'ignore nowadays so that font-latex is > not loaded? Would that make AUCTeX use tex-mode.el's font-lock rules? >> Good question. We usually use `declare-function' for these, but >> admittedly, it's not a great solution. > I see. The reason for the code above is that foo is only callable in > very special conditions. That's what I expected. We also have such code in various parts of Emacs. But we don't have a really good solution w.r.t to silencing those warnings. One potential solution I haven't investigated is to create a new `require-autoload' which behaves somewhat like `require' (when interpreted) but which the compiler would replace by a bunch of autoloads (auto-generated by the compiler by taking the intersection of the functions provided by the `require' and the functions called in the file). So you'd replace that code with (require-autoload 'url-util) (defun foo () (url-util-* ...)) and url-util would only be loaded once you call `foo'. Maybe `require-lazy' would be a better name for it, but in any case as long as it's not implemented, its name doesn't matter much. Stefan ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Stefan Monnier writes: >>> Or you could turn them into macros. >> Indeed, that looks like a typical use-case for macros, but I'm rather >> sure that there's a good reason that the auto parser stuff is like it >> is. David? > > Whatever the reason, looking at the code of TeX-auto-add-type, I think > it *really* should be turned into a macro, and use defvar/defalias > instead of set/fset. Yes, I've done that now in a local branch. Seems to be the way to go, but I need to do some more testing before pushing out that change. >> While we are at it: David, is there any reason why somebody would >> want to set TeX-install-font-lock to 'ignore nowadays so that >> font-latex is not loaded? > > Would that make AUCTeX use tex-mode.el's font-lock rules? TeX-install-font-lock has 3 possible values. font-latex-setup uses AUCTeX's rules, tex-font-setup uses tex-mode's rules, and ignore doesn't set up any font-lock rules. (So my question was a bit misleading.) font-latex has some nice goodies like being able to add custom font-locking rules for your own macros/environments very easily. > Maybe `require-lazy' would be a better name for it, but in any case as > long as it's not implemented, its name doesn't matter much. Yup. Bye, Tassilo ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Stefan Monnier writes: >> That's ok. But if the style files were compiled, adding the requires >> into the style files would make the compilation take minutes, because >> each style file compilation would need to load the core files first. > > Yup. I personally don't see much need to add the `require's in those > style files. Then again, I'm not too bothered by lingering warnings. The problem is that the mass of warnings makes it hard to spot warnings that are really defects. However, now I've seen that adding requires to the style files doesnt't help in the case where one style files uses vars/funs from another style file (e.g., there's pstricks.el and several other sub-styles that use funs/vars from the former, because they can assume that it's loaded beforehand). But style files can't be required cause they don't provide a feature... Bye, Tassilo ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
