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

[Andrea Corallo <akrl@sdf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juanma Barranquero <lekktu@gmail.com>
>> Date: Fri, 18 Nov 2022 10:05:50 +0100
>> Cc: akrl@sdf.org, 59334@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