From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: master f8bb6cca33: Return the same file from locate-file in nativecomp and non
Date: Mon, 14 Mar 2022 12:57:45 -0400 [thread overview]
Message-ID: <jwvpmmoec4v.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83cziok3pl.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 14 Mar 2022 16:29:10 +0200")
> E.g., is the result below expected, or is it a bug?
>
> (locate-file "simple" native-comp-eln-load-path '(".eln"))
> => nil
I assume you don't have a `simple.eln` file in your
`native-comp-eln-load-path`, so nil seems correct.
> Or what about load-history -- why does it only show the *.elc files
> loaded by the session, but not the *.eln files?
To better preserve compatibility.
> (This discussion was triggered by a conflict between load-history and
> locate-file, so load-history is definitely relevant to the issue
> at hand.)
The problem can't be "a conflict between load-history and locate-file".
There needs to be some code that links the two and tweaking
`locate-file` so it does what we happen to need can't the answer,
instead it has to be in the code that links the two.
Again `locate-file` is just a generic function, like
`locate-dominating-file`, or `file-attributes`. If it doesn't do quite
what a specific function needs (e.g. `load` or `locate-library`), then
either that function needs to supplement `locate-file` with what it
needs, or it needs to use some other function.
You're right that the `openp` code probably needs further fixes to
better separate the `load` case from the other cases. The way the
redirection from `.elc` to `.eln` was added to it is rather messy for
those uses that aren't `load`. It happens to work OK largely because
executables tend not to use a `.elc` extension.
> should perhaps stop and think about this a bit harder. E.g., maybe a
> simpleton that locate-file is no longer satisfies us for looking up
> Lisp files?
That's already the case: `load` supplements the code of `locate-file`
with some extra processing to look for a `.eln` after it found a `.elc`.
But in theory this replaces a call to `locate-file` with two calls to
that function (one to look for a file through `load-path` and then
another to look for a .eln version of the result through the
`native-comp-eln-load-path`), so it's not really an argument that
`locate-file` no longer satisfies us.
[ In practice it's implemented in a much more intertwined way in
`openp`, and the second loop (through `native-comp-eln-load-path`
doesn't reuse the code of locate-file/openp). ]
> Is there such a big difference between "ask" (which you didn't) and
> "would suggest" (which you did)?
All I can say is that when I wrote that sentence I did not think it was
appropriate to put it right away into `emacs-28` (instead I thought,
like Lars, that it was better to see how it fares in `master` first).
Stefan
next prev parent reply other threads:[~2022-03-14 16:57 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <164712074096.14747.18124931770043811100@vcs2.savannah.gnu.org>
[not found] ` <20220312213221.451B3C01684@vcs2.savannah.gnu.org>
2022-03-12 21:47 ` master f8bb6cca33: Return the same file from locate-file in nativecomp and non Stefan Monnier
2022-03-12 21:51 ` Lars Ingebrigtsen
2022-03-12 23:23 ` Stefan Monnier
2022-03-12 23:40 ` Lars Ingebrigtsen
2022-03-13 4:51 ` Stefan Monnier
2022-03-13 6:01 ` Eli Zaretskii
2022-03-13 14:16 ` Lars Ingebrigtsen
2022-03-13 14:26 ` Stefan Monnier
2022-03-13 14:40 ` Lars Ingebrigtsen
2022-03-13 17:15 ` Eli Zaretskii
2022-03-14 0:20 ` Stefan Monnier
2022-03-14 14:29 ` Eli Zaretskii
2022-03-14 16:57 ` Stefan Monnier [this message]
2022-03-14 17:22 ` Eli Zaretskii
2022-03-14 18:09 ` Stefan Monnier
2022-03-14 22:29 ` Corwin Brust
2022-03-15 13:11 ` Stefan Monnier
2022-03-13 16:59 ` Eli Zaretskii
2022-03-13 22:16 ` Lars Ingebrigtsen
2022-03-14 3:26 ` Eli Zaretskii
2022-03-14 2:57 ` Stefan Monnier
2022-03-14 3:38 ` Eli Zaretskii
2022-03-14 4:04 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvpmmoec4v.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.