From: Christoph via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 66534@debbugs.gnu.org
Subject: bug#66534: 30.0.50; [PATCH] Expand file-name of ~/.emacs before attempt to load it
Date: Sat, 14 Oct 2023 11:04:14 +0200 [thread overview]
Message-ID: <CAK9rt1pjAci_JocMibY=k+icW+LkMz+5RaLcSKMRVrMppRQuOg@mail.gmail.com> (raw)
In-Reply-To: <83r0lxsnhz.fsf@gnu.org>
On Sat, Oct 14, 2023 at 8:54 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Fri, 13 Oct 2023 20:41:16 +0200
> > From: Christoph via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >
> > I noticed that during startup, emacs tries to load ~/.emacs (with
> > different extensions) many times over. You can see this by using
> > strace and tracing the openat syscall. The problem is, that `load'
> > does not expand the ~/ in the filename passed to it. So it does not
> > recognize the file as being absolute and tries to resolve it using
> > the load-path.
> >
> > While resolving the path in the openp function in lread.c,
> > `expand-file-name' is used with the default directory being the
> > elements of the load-path. Since for `expand-file-name', ~/.emacs is
> > an absolute path, it returns the path unchanged, and load tries to
> > load ~/.emacs many times over.
>
> I don't understand what you are saying here. The last sentence is
> incorrect, as evidenced by the following:
>
> (expand-file-name "~/.emacs" "/tmp")
> => "/home/eliz/.emacs"
>
> IOW, "~/.emacs" is indeed treated by Emacs as an absolute file name,
> but expand-file-name does NOT return "~/.emacs" unchanged.
What I meant is "unchanged" in the regard to the default
directory. You can give any default directory to expand-file-name and
it will always return the first argument in its expanded form, if the
expanded form of the first argument is an absolute path.
>
> So please explain what exactly is the problem you see here, and in
> particular what issues that problem causes in your case.
>
> Thanks.
If you start Emacs without an ~/.emacs file, and with using .emacs.d
and not .config/emacs, I think there is a difference as well, Emacs
will try to load ~/.emacs `(length load-path)' times. If I start
Emacs with strace -e openat I see the following lines 147 times:
openat(AT_FDCWD, "/home/chris/.emacs", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
openat(AT_FDCWD, "/home/chris/.emacs.gz", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/chris/.emacs.so", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/chris/.emacs.so.gz", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/chris/.emacs.elc", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/chris/.emacs.elc.gz", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/chris/.emacs.el", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/chris/.emacs.el.gz", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
But Emacs should only try to load the file once. The problem is that
the path to ~/.emacs is not expanded before it is handed to `load' and
load basically does:
(dolist (path load-path)
(low-level-load (expand-file-name "~/.emacs" path)))
where low-level-load is some magic function which really loads a file.
There is off course more going on, like iterating over the extension
and such, but I want to keep it simple, since I am not familiar with
it at all.
`load' does check if the given path is absolute and
changes its behavior. If the path is absolute, `load' does not take the
load-path into account, but paths beginning with "~/" are not recognized as
beeing absolute, hence the paths should be expanded before passing them
to `load'.
Because all the other paths to init files (early-init.el and init.el)
are expanded before they are passed to `load', I think "~/.emacs"
should be expanded as well.
There is also the question if `load' itself should be able to handle
paths that begin with "~/" correctly, or if the user is expected to
expand paths before passing them to `load'.
Regards, Christoph
next prev parent reply other threads:[~2023-10-14 9:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-13 18:41 bug#66534: 30.0.50; [PATCH] Expand file-name of ~/.emacs before attempt to load it Christoph via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-14 6:54 ` Eli Zaretskii
2023-10-14 9:04 ` Christoph via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-10-23 15:56 ` Christoph via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-14 7:25 ` Andreas Schwab
2023-10-14 9:05 ` Christoph via Bug reports for GNU Emacs, the Swiss army knife of text editors
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK9rt1pjAci_JocMibY=k+icW+LkMz+5RaLcSKMRVrMppRQuOg@mail.gmail.com' \
--to=bug-gnu-emacs@gnu.org \
--cc=66534@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=just.mychris@googlemail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).