Re: [O] Keeping an eye on byte-compilation warnings
Hi Achim, Achim Gratz strom...@nexgo.de writes: In org-fixup-indentation: org.el:7368:32:Warning: reference to free variable `org-property-end-re' In org-set-property: org.el:14316:34:Warning: reference to free variable `fn' Both fixed, thanks! -- Bastien
Re: [O] Keeping an eye on byte-compilation warnings
Bastien b...@altern.org writes: Thanks for the heads up. I'll be more careful about this. In org-fixup-indentation: org.el:7368:32:Warning: reference to free variable `org-property-end-re' In org-set-property: org.el:14316:34:Warning: reference to free variable `fn' Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Keeping an eye on byte-compilation warnings
Achim Gratz strom...@nexgo.de writes: John Wiegley jwieg...@gmail.com writes: Maybe we're all using different versions of Emacs, but I find that byte-compilation warnings keep increasing as time goes by. I'd like to ask people to compile their code before committing, to keep the build log clean. It looks messy when there are lots of unnecessary warnings. Thank you for bringing this up (again). A few comments: The function that calls org-agenda-todo probably belongs into org-agenda. I moved `org-agenda-todo-yesterday' to org-agenda.el. I moved org-find-visible/invisible to org.el. Thanks! -- Bastien
Re: [O] Keeping an eye on byte-compilation warnings
Hi John, John Wiegley jwieg...@gmail.com writes: Maybe we're all using different versions of Emacs, but I find that byte-compilation warnings keep increasing as time goes by. I'd like to ask people to compile their code before committing, to keep the build log clean. It looks messy when there are lots of unnecessary warnings. Thanks for the heads up. I'll be more careful about this. -- Bastien
Re: [O] Keeping an eye on byte-compilation warnings
At Sat, 13 Aug 2011 16:49:50 -0500, John Wiegley wrote: Maybe we're all using different versions of Emacs, but I find that byte-compilation warnings keep increasing as time goes by. I'd like to ask people to compile their code before committing, to keep the build log clean. It looks messy when there are lots of unnecessary warnings. +1 Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpS8wnCKnrLn.pgp Description: PGP signature
Re: [O] Keeping an eye on byte-compilation warnings
John Wiegley jwieg...@gmail.com writes: Maybe we're all using different versions of Emacs, but I find that byte-compilation warnings keep increasing as time goes by. I'd like to ask people to compile their code before committing, to keep the build log clean. It looks messy when there are lots of unnecessary warnings. Thank you for bringing this up (again). A few comments: The function that calls org-agenda-todo probably belongs into org-agenda. The function org-copy-visible uses two function from org-exp.el, but probably doesn't belong there, so a declaration of these two functions would be needed. I don't think autoloading during compile is appropriate (does that even work?), and I'm not a huge fan of using require in eval-when-compile for in-package functions (it's OK for external dependencies). In a nutshell, that only works correctly when the dependencies between the lisp files are correctly defined or if the byte-compiled files are always removed before starting a new byte-compile. Since there are quite a few circular dependencies introduced by using require rather than declarations, only the latter currently works (and hence the usual incantation of 'make clean make compile', which would not be necessary otherwise). Can you recommend a package that can extract the dependencies and perhaps highlight the circulars? There is a page in EmacsWiki with some libraries, but I haven't worked with them yet. It seems like a good idea to try and untangle that cicular dependencies mess... Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Keeping an eye on byte-compilation warnings
Hi John, John Wiegley jwieg...@gmail.com writes: lisp/org-list.el: In org-list-send-item: org-list.el:1456:56:Warning: Function `sort*' from cl package called at runtime I've fixed this one in d24a141. There was no reason to use sort* instead of sort. Thanks for this! lisp/org-table.el: In org-table-eval-formula: org-table.el:2437:23:Warning: assignment to free variable `duration-output-format' org-table.el:2557:34:Warning: reference to free variable `duration-output-format' In org-table-time-string-to-seconds: org-table.el:3252:11:Warning: assignment to free variable `minus' org-table.el:3257:13:Warning: reference to free variable `minus' I just fixed those, thanks again. -- Bastien
[O] Keeping an eye on byte-compilation warnings
Maybe we're all using different versions of Emacs, but I find that byte-compilation warnings keep increasing as time goes by. I'd like to ask people to compile their code before committing, to keep the build log clean. It looks messy when there are lots of unnecessary warnings. Here's what I'm seeing now: --8---cut here---start-8--- lisp/org.el: In end of data: org.el:20575:1:Warning: the following functions are not known to be defined: org-agenda-todo, org-find-invisible, org-find-visible --8---cut here---end---8--- These represent a cyclic dependency. Should org.el contain some autoload forms during compilation? --8---cut here---start-8--- lisp/org-footnote.el: In org-footnote-in-valid-context-p: org-footnote.el:185:37:Warning: reference to free variable `message-cite-prefix-regexp' In end of data: org-footnote.el:869:1:Warning: the following functions are not known to be defined: message-point-in-header-p, org-icompleting-read --8---cut here---end---8--- Is there a reason org-footnote doesn't just require org? --8---cut here---start-8--- lisp/org-list.el: In org-list-send-item: org-list.el:1456:56:Warning: Function `sort*' from cl package called at runtime --8---cut here---end---8--- I've fixed this one in d24a141. There was no reason to use sort* instead of sort. --8---cut here---start-8--- lisp/org-table.el: In org-table-eval-formula: org-table.el:2437:23:Warning: assignment to free variable `duration-output-format' org-table.el:2557:34:Warning: reference to free variable `duration-output-format' In org-table-time-string-to-seconds: org-table.el:3252:11:Warning: assignment to free variable `minus' org-table.el:3257:13:Warning: reference to free variable `minus' --8---cut here---end---8--- I think an empty defvar during compilation is in order here, and that minus is simply missing from the `let'. Thanks, John
