Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz <Stromeko@nexgo.de>]

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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves