bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#62767: 29.0.90; [PATCH] *lisp/emacs-lisp/package.el: set variables a


From: Stefan Monnier
Subject: bug#62767: 29.0.90; [PATCH] *lisp/emacs-lisp/package.el: set variables after info package
Date: Mon, 17 Apr 2023 12:30:19 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

> OK, then we still have to find out if these changes are safe.  As
> mentioned before, I hesitate in using `with-eval-after-load', probably
> because of the complicated history of `eval-after-load'.  I suppose that
> Stefan might know more (as it is due to him that I am careful here), so
> I have added him to the thread.

The problem with eval-after-load is not the history but the fact that
it has various corner-case caveats.

(with-eval-after-load "compile" ...) for example makes it unclear
exactly when it should be executed, e.g.:

   (load "compile")                          => yes clearly.
   (load "compile.el")                       => probably, yes.
   (load "srecode/compile.el")               => probably not.
   (load "/foo/bar/lisp/compile.el")         => hmm... yeah, I think so.
   (load "/foo/bar/lisp/srecode/compile.el") => hmm... nah, maybe not.

The next game is to try and guess what the code does, to see when it
matches expectations.

The use (with-eval-after-load 'info ...) is much better in this respect
because it's not linked to the file name but to the feature name, which
is precise.

But there's still the issue of exactly when this is executed.  Should it
be executed just the next time the file is loaded (usually what's
wanted), or every other time after that as well (what actually happens)?

Also the implementation for the good case where we provide a feature
name rather than a file name is a bit roundabout/fiddly.  This is an
internal problem, so any bug there can be fixed, thus it's probably not
a good reason not to use it, but it still makes me prefer to avoid it :-)

I wish there was an easier way to add to `Info-directory-list`.
That variable is set in a fairly delicate manner, so I think Eli would
be better placed to come up with a better long term solution.
Maybe we should just add a (preloaded) `Info-extra-directory-list`?

In the mean time, Lin Sun's patch is probably "as good as it gets" if
you want to load `info.el` lazily (which I obviously didn't bother to do
when I wrote that code :-)


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]