Re: master f8bb6cca33: Return the same file from locate-file in nativecomp and non

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 13 Mar 2022 10:26:48 -0400
> 
> >> I object to such backward-incompatible change in a public API.  Please
> >> revert that change.
> > Stefan's patch does not change the behaviour of locate-file (after my
> > patch).  It does change the behaviour of locate-file-internal, but
> > that's not a public function (and it's only used in locate-file).  So
> > I'm not sure what you mean here.
> 
> AFAIK it reverts the behavior of `locate-file-internal` to that of
> Emacs-27

Emacs 27 behavior cannot guide us here, because the *.eln files and
the aspects they bring into the issue are new.

> and I think the change in Emacs-28 is just a bug (an oversight, I
> suspect)

How can you think that when this "bug" endured more than a year of
testing since the nativecomp branch was merged, including the pretest
until now?  The only place where this issue happens is in a test, and
we can easily change the test to adapt it to the actual behavior,
should we decide that it's the correct behavior--and I'm not yet
saying it has to be, but I'm not yet convinced it's wrong, either.
The whole issue is somewhat non-trivial, because load-history doesn't
(AFAIK) record the *.eln files when they are loaded, but instead
"lies" to us by mentioning only the *.elc files.  I'm not sure we
shouldn't change that, for example.

> so I'd even suggest we install my patch in `emacs-28`.

Do we want to release Emacs 28 any time soon, or do we want to
continue dragging our feet by making destabilizing changes in it?  The
behavior of locate-file on emacs-28 doesn't cause any problems that we
know about, so what would be our reason for making such a problematic
change and delaying the release?

Look, the native-compilation stuff introduces complexity into Emacs
whose implications we don't yet understand well enough.  It will take
time to collect enough experience and see what else should be done and
changed as result.  I submit that your opinion that
"locate-file-internal should not magically replace `.elc` files with
`.eln` files" is not based on enough data for us to change the
behavior that worked well for the last year.

Bottom line: I see no reason to rush in this matter, especially since
the "problem" so far exists only in a test.