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

[Eli Zaretskii]

> 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?

> I've checked that gethash returns a value, but not for the file's existence 
> because in that case comp already
> complains:
> 
> 2022-11-18 10:01:15+0100 Warning (comp): Cannot look up eln file as no source 
> file was found for
> d:/Home/.emacs.d/init.elc
> 
> The warning above is only for the unlikely case that user-init-file points to 
> an .eln but the gethash lookup
> returns nil.

SGTM, thanks.