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

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Sun, 13 Mar 2022 15:16:46 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.

I mean locate-file-internal.  It behaved like that since the merge of
native-compilation, which happened more than a year ago.  Emacs 28
will be released very soon with that behavior, which means that
behavior will be out there until Emacs 29.1 is released, at least two
years from now?  And all that just because some test failed?  Sorry, I
cannot agree to that.

It is very easy, albeit less elegant, to add a new optional argument;
then we can have the cake and eat it, too (provided that this solution
is at all correct and doesn't cause regressions, which I'm not sure is
true).

More generally, I'm not at all convinced that the problem, as
presented in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51308#14,
indeed needs a solution that makes locate-file behave the same as it
did in Emacs 27, because the *.eln files introduce new aspects into
the stuff that 'load' and 'load-history' intend to support.  We didn't
discuss this enough, and I'm not even sure we have a common POV on
this.

Bottom line: this needs further discussion.