GNU bug report logs -
#35022
custom-add-load, custom-load-symbol don't support filenames with directory components
Previous Next
Reported by: Allen Li <darkfeline <at> felesatra.moe>
Date: Wed, 27 Mar 2019 19:47:02 UTC
Severity: wishlist
Found in version 26.1
Done: Allen Li <darkfeline <at> felesatra.moe>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sat, 13 Apr 2019 21:57:02 +0000
with message-id <CADbSrJwTSa+5FobrmhXUsVeWLkOhQMB0YDzrmvQht7L3G+H1Og <at> mail.gmail.com>
and subject line Re: bug#35022: 26.1; Load order of custom-autoload, custom-load-symbol, custom-loads is backward?
has caused the debbugs.gnu.org bug report #35022,
regarding custom-add-load, custom-load-symbol don't support filenames with directory components
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
35022: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=35022
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
I just spent some time tracking down an unexpected behavior in custom
autoloads.
The custom-autoload function is used in autoloads/loaddef files to set
up custom variables. custom-autoload adds a load path to the
custom-loads property of a variable. This property is then used in
custom-load-symbol to load each of the load paths.
The problem is that custom-autoload adds load paths to the front of
custom-loads, and custom-load-symbol loads the paths in forward order.
This is unexpected because if the site distributes a package foo and the
user installs their own version of foo, the site custom-autoload will be
called first:
;; Called from site-start
(custom-autoload 'foo-some-variable "path/to/site/foo" nil)
;; Called from init.el/package-initialize
(custom-autoload 'foo-some-variable "path/to/user/foo" nil)
In this case the custom-loads property will be
("path/to/user/foo" "path/to/site/foo")
The user version will be loaded first, and the site version will be
loaded later, overriding the user version.
This behavior is unexpected; the user would expect that their version of
foo overrides the site version of foo. Furthermore, this behavior is
somewhat non-deterministic; site overrides foo *only if* foo is loaded
via setting foo-some-variable with customize. If foo is loaded normally
(e.g. with require), then the user version of foo will be loaded in
preference to the site verison of foo.
I have attached a patch fixing this.
Note that this is technically a breaking change; however I really doubt
any one is intentionally relying on this behavior. I consider this a
bugfix and I think there are probably users who don't realize that they
are suffering from this bug because it's so subtle.
In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.24), modified by Debian
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Debian GNU/Linux rodete (upgraded from: Ubuntu 14.04 LTS)
[0001-Load-custom-variable-dependencies-in-FIFO-order.patch (text/x-patch, attachment)]
[Message part 5 (message/rfc822, inline)]
On Thu, Apr 11, 2019 at 1:54 AM Noam Postavsky <npostavs <at> gmail.com> wrote:
>
> Allen Li <darkfeline <at> felesatra.moe> writes:
>
> > But not for this:
> >
> > ;; Called from site-start
> > (custom-autoload 'foo-some-variable "some/path/to/foo" nil)
> > ;; Called from init.el/package-initialize
> > (custom-autoload 'foo-some-variable "foo" nil)
> >
> > I'm not sure yet what the proper approach for my problem is.
>
> Would it be too impertinent to suggest the proper aproach is this:
>
> ;; Called from site-start
> (add-to-list 'load-path (expand-file-name "some/path/to"))
> (custom-autoload 'foo-some-variable "foo" nil)
> ;; Called from init.el/package-initialize
> (custom-autoload 'foo-some-variable "foo" nil)
The site-start is shipped by the distro which I don't have control over.
>
> Otherwise, I guess extending custom-add-load and custom-load-symbol to
> handle entries of the form (LIBRARY . RELATIVE-NAME) could make sense.
After some deliberation, I think custom-add-load's current behavior is correct,
so I'll take my issue downstream.
Thanks
This bug report was last modified 6 years and 37 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.