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

[Eric Schulte <schulte.eric@gmail.com>]

Achim Gratz <Stromeko@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