Achim Gratz <strom...@nexgo.de> writes: > Bastien writes: >> Yep, typo. But the 'mustsuffix trick is to force loading ".el" (and >> not ".elc" files, right? My question is: when is it necessary? > > The 'mustsuffix argument prevents consideration of the filename without > the extensions listed in load-suffixes. In other words, when you are > trying to load feature 'x, a file named just "x" does not satisfy the > requirement as it otherwise would. On the other hand, it does not > prevent using "x.el.gz" instead of "x.el" as 'nosuffix does. > >> I'm trying to consider real use-cases, with a sense of "real" close to >> "not so improbable". I don't see why Org should take care of users >> who are pervert enough to gzip their org-loaddefs.el... but maybe I >> lack imagination, as usual :) > > This is a real use case. Installation with compression is a standard > feature of Emacs and just currently not supported by the build system, > mainly due to "little" problems like the above. Emacs' current > installer itself compresses the source files only when there's a > byte-compiled file around, so any recent Emacs would automatically have > a file "org-loaddefs.el" in load-path, although some packagers have > their own ideas about this. You should generally expect that the > installed files, whether sources or byte-compiled files could have been > compressed. > > Now if someone decides to compress the lisp folder for their own org > installation and aren't taking care to exclude the autoload files, then > this is what they get from 'emacs -Q": > > --8<---------------cut here---------------start------------->8--- > (require 'find-func) > => find-func > (find-library-name "org-loaddefs.el") > => "/usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el" > (add-to-list 'load-path "~/lisp/org-mode/lisp") > => (~/lisp/org-mode/lisp …) > (find-library-name "org-loaddefs.el") > "/home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz" > (load "org-loaddefs.el" t nil t) > => Loading /usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el > (source)...done > --8<---------------cut here---------------end--------------->8--- > > This is decidedly not what you wanted to achieve and outright devious, > given that you don't even get the hint from *Messages* what file > actually got loaded when the second argument to load is also "t". > > --8<---------------cut here---------------start------------->8--- > (require 'org-macs) > (let ((load-suffixes (list ".el"))) > (org-load-noerror-mustsuffix "org-loaddefs")) > => Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz... > => uncompressing org-loaddefs.el.gz...done > => Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz...done > --8<---------------cut here---------------end--------------->8--- > > This on the other hand is what was intended to happen. > > The problem is that for the previous discussion "(require 'org-macs)" > was effectively a NOP because 'org-macs was already loaded from a > different place. If you want to fix it, then that's where the effort > should be directed (org-reload already does that and it's not difficult > to do here either). > > […] >> But I know your answer, `find-library' does not give the library from >> which functions have been autoloaded. > > I might harp too much about this, but it's not the answer to this > question. But see above how find-library can fool you when you are > actually using load with optional arguments instead. >
These sounds like a Emacs-wide (or possibly find-library) issues, rather than anything specific to Org, outlining, agendas or plain text notes. Shouldn't this sort of discussion and development be taking place on emacs-dev and in non-org Emacs libraries. In my opinion the only reason to try to solve these issues in Org-mode proper is if we are testing out new functionality which will eventually be adopted by core Emacs. Otherwise I would argue that such development within Org-mode is a waste of Org-mode development time, effort and code complexity. At the least perhaps such load/require mechanisms should be extracted into a separate library with no Org-mode specific code. Then Org-mode could make use of these libraries, but so could other large systems distributed with Emacs but developed independently (e.g., gnus). Best, -- Eric Schulte http://cs.unm.edu/~eschulte
