[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Tassilo Horn t...@gnu.org 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 d...@gnu.org 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-type-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 monn...@iro.umontreal.ca 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 monn...@iro.umontreal.ca 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
[Bug-AUCTeX] bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile
Glenn Morris r...@gnu.org 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. Disables 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 r...@gnu.org 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 yourpackage-here (lambda () (TeX-add-symbols '(your-first-macro-here 1) ;has one arg '(your-2nd-macro-here 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. Disables 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 t...@gnu.org: 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 t...@gnu.org 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 giordano.m...@libero.it 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
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 thierry.volpia...@gmail.com 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 t...@gnu.org writes: Thierry Volpiatto thierry.volpia...@gmail.com 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
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 r...@gnu.org 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 r...@gnu.org 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 `foo-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 `foo-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
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
