[bug#67260] [PATCH emacs-team v10 0/7] Preload most of the things

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Sonntag, dem 18.02.2024 um 00:56 +0000 schrieb Suhail:
> "Liliana Marie Prikler" <liliana.prikler@gmail.com> writes:
> 
> > I don't think our choice of putting Emacs itself last is wrong
> > here.
> 
> I'm not sure I understand.  Just to be clear (please ignore in case
> this was already clear), in non-Guix Emacs the situation is as
> follows:
> 
> 1. The directory where 'mule-util and 'ucs-normalize are located
>    ("/usr/share/emacs/29.2/lisp/international") occurs in the load-
> path.
>    And this entry occurs in the load-path AFTER
>    "/usr/share/emacs/29.2/lisp".
> 
> 2. The directory where 'term/internal is located
>    ("/usr/share/emacs/29.2/lisp/international") does NOT occur in the
>    load-path (and thus trivially doesn't occur before the
>    "share/emacs/29.2/lisp" entry).
Directory (2) is the same as directory (1).  I think you meant
$prefix/share/emacs/$emacs_version/lisp/term?  

> After installing the v10 patch series, both 1 and 2 hold in Guix
> Emacs as well.  However, Guix Emacs's behaviour when locating/loading
> natively-compiled versions of the above three features differs from
> the behaviour in non-Guix Emacs.  Specifically, 1 and 2 above seem to
> pose a problem for only Guix Emacs and after remedying 1 and 2 above,
> as in the test script, the tests pass.
From my understanding (1) poses a problem because it messes up the way
our patch computes relative file names.  We could fix that with the
newly introduced NATIVE_COMP_BOGUS_DIRS… hopefully.

> All this to say, if by "putting Emacs itself last" you meant the
> change I made to the test script to make the tests pass, then while
> it may not be wrong, it also isn't correct either (seeing how it's
> not needed in non-Guix Emacs).  
The last (first) directory in EMACSLOADPATH (EMACSNATIVELOADPATH) is
$prefix/share/emacs/$emacs_version/lisp ($prefix/lib/emacs/…) on Guix
System.

> My goal in sharing the patch was not to suggest a fix, but rather to
> possibly highlight something correlated with the cause of the problem
> we're observing.
> 
> > Can you do some more research as to how this confusion comes to be?
> 
> Since I have less familiarity with the internals of how Emacs locates
> natively-compiled features and loads them, I'm not sure where to
> begin.  Do you have some concrete suggestions?


> What (I believe) we know:
> 
> - Not all the .eln entries in the "preloaded" 
>   native-comp-eln-load-path directory in Emacs are actually loaded by
>   default.  This doesn't directly concern the issue, but it's to
>   clarify that my use of the term "preloaded" in this thread is
>   regarding the former and not the latter.
Well, it does concern the issue in that locating such files becomes
even harder.  We need some place to put them and complicating these
things for preloaded packages (for no real reason, might I add) is not
fun.

> - The issue of whether natively compiled variants are loaded or
>   depending on load-path order doesn't seem to affect packages that
>   aren't built-in.  Specifically, if the load-entry for a
>   not-built-in package is put after the "share/emacs/29.2/lisp"
>   entry, Guix Emacs is still able to load the natively-compiled
>   variant.
Well, obviously not.  Those are found under their packages and are
probably still within a flat directory hierarchy.

> - It is unclear why other packages such 'log-edit, 'find-func
>   etc. (built-in, but not loaded by default, having their load-entry
>   after the "share/emacs/29.2/lisp" entry) aren't affected.
Update your script to account for them and we shall find out.

Cheers