emacs-devel
[Top][All Lists]
Advanced

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

Re: Add a configure option for NATIVE_FULL_AOT?


From: Eli Zaretskii
Subject: Re: Add a configure option for NATIVE_FULL_AOT?
Date: Wed, 18 Aug 2021 19:43:23 +0300

> Date: Wed, 18 Aug 2021 18:34:55 +0200
> From: tomas@tuxteam.de
> Cc: emacs-devel@gnu.org
> 
> > > When the user wants to change a distribution-specific .el, the default
> > > way to do it would be to make a user-writable copy somewhere in a
> > > user-controlled directory (ISTR there was a mechanism doing this
> > > semi-transparently, but I may be confused). If `load-path' is set up
> > > correctly, the user's variant takes precedence. Same would go for
> > > .eln files resp. native-comp-eln-load-path, right?
> > 
> > Nominally, yes.  But then you have 2 copies of the same .eln file, in
> > 2 different places.
> 
> They would be different, one of them from an .el with user changes.

Sure, that's my point.

> > The preloaded *.eln files are stored there, yes.
> 
> But why on the "least precedence" slot, i.e. in the place at the
> list's tail? I'd have expected them to be stored in the place
> at the list's head.
> 
> >                                                  How else would you
> > arrange for them to be of the least precedence, when lists are
> > generally searched head to tail?
> 
> Why would I want to arrange "them" [1] to be of the least precedence?
> A freshly user-compiled file should have the highest precedence, IMO.

How would that precedence work, except by relying on the order of the
directories in the list?

> [1] provided our "them" refers to the same thing: "the .eln files
>    freshly compiled in the user's behalf, because Emacs has seen
>    an .el(c) file it had not seen before"

I don't understand this part.  The *.elc files add yet another
"interesting" aspect to the issue, but that's a story for another day.



reply via email to

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