all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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




  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.