GNU bug report logs - #59334
29.0.50; loading native-compiled init file sets user-init-file to .eln

Previous Next

Full log

Message #70 received at 59334 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 59334 <at> debbugs.gnu.org
Subject: Re: bug#59334: 29.0.50; loading native-compiled init file sets
 user-init-file to .eln
Date: Fri, 18 Nov 2022 20:02:36 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Juanma Barranquero <lekktu <at> gmail.com>
>> Date: Fri, 18 Nov 2022 10:05:50 +0100
>> Cc: akrl <at> sdf.org, 59334 <at> debbugs.gnu.org
>> 
>> > I thought about a possibility that the session loaded a .eln file, but
>> > then the user or some Lisp explicitly loaded the .el file by hand.
>> > I'm not sure in this case the hash table is updated. 
>> 
>> That's a whole another problem, isn't it?
>
> Not necessarily.
>
>> On one hand, it would not affect user-init-file, as it's not the
>> usual startup procedure.
>
> It could be part of startup if the forced loading of "init.el" is in
> the code inside user's init file itself.  Crazy, I know, but not
> impossible.
>
>> And, on the other hand,
>> my patch sets user-init-file to the source .el, so after reloading that file it would still have the right value,
>> wouldn't it?
>
> If that is the same file, yes.  But what if there's an init.el in
> another place?
>
> In any case, we don't need to keep arguing about this, since your
> pat6ch indeed uses gethash only if the init file has the .eln
> extension.
>
>> The original code is untouched, other than changing `when' to `if'; the else part deals with the .eln.
>
> I think we should compare the extensions case-insensitively, but other
> than that, this LGTM.
>
> Andrea, any comments?

Agree and I don't have any further comment.

Thanks

  Andrea

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.