GNU bug report logs - #69467
29.2; user-init-file set to .../lisp/progmodes/compile.el.gz

Previous Next

To reply to this bug, email your comments to 69467 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Cc: Jonas Bernoulli <jonas <at> bernoul.li>
Subject: 29.2; user-init-file set to .../lisp/progmodes/compile.el.gz
Date: Fri, 01 Mar 2024 01:23:50 +1300

[Message part 1 (text/plain, inline)]

I recently encountered this undesirable side-effect when using the
https://github.com/emacscollective/auto-compile library in conjunction
with a byte-compiled init file.  The combination is reliably resulting
in `user-init-file' being set to the .../lisp/progmodes/compile.el.gz
path, with ensuing chaos (e.g. customized settings being written to
that file -- I first became aware of this problem while using emacs -Q
when it suddenly acquired some custom faces from my regular config as
something loaded the compile library!).

The purpose of the auto-compile package is to ensure that .elc files
are always up-to-date and loaded in preference to .el files.  I've been
using it for many years and wasn't aware of having had any issues with
it in the past, but I do not typically have a byte-compiled init.elc
file.  The auto-compile code advises `load' and `require' (which does
seem like it could present risks), however it seems so very odd to me
that user-init-file could end up with this value for any reason that
it seems like it might ultimately be an Emacs bug.

I raised it with the auto-compile maintainer (Jonas Bernoulli, CC'd)
at https://github.com/emacscollective/auto-compile/issues/33 and we
couldn't make sense of it at the time, so I'm escalating it here.

The attached bash shell recipe reproduces the issue in Emacs 29.
I can reproduce it in all of Emacs 27, 28, 29, 30 (and not 26.3 or
25.3), but this recipe uses the --init-directory option which was
added in 29.1.

(See attached script.)

The echo area in the final instance of Emacs should report the path to
compile.el.gz (and re-running the final "touch init.el && ..." command
will repeat that result each time).


If I put (debug) at the top of compile.el.gz then I get the following
backtrace, so we can see how/why compile.el is getting involved, but
it just seems very wrong for that path to be able to end up being the
user-init-file value.


Debugger entered: nil
  byte-code(...)
  compilation-mode()
  emacs-lisp-compilation-mode()
  byte-compile-log-file()
  byte-compile-from-buffer(#<buffer  *Compiler Input*>)
  byte-compile-file("/tmp/autocomp/init.el")
  auto-compile--byte-compile-file("/tmp/autocomp/init.el")
  auto-compile-on-load("/tmp/autocomp/init" nil)
  load <at> auto-compile("/tmp/autocomp/init" noerror nomessage)
  apply(load <at> auto-compile ("/tmp/autocomp/init" noerror nomessage))
  load("/tmp/autocomp/init" noerror nomessage)
  startup--load-user-init-file(#f(compiled-function () #<bytecode 
-0x54c765b3b165b77>) #f(compiled-function () #<bytecode 
-0xe2e004ca56aeafc>) t)
  command-line()
  normal-top-level()


As it seems to have started in Emacs 27, my *guess* is that it's
connected to the early-init.el system which was added in Emacs 27,
but I've not dug any further at this stage.

-Phil


In GNU Emacs 29.2 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw scroll bars) of 2024-01-19 built on phil-lp
Repository revision: ef01b634d219bcceda17dcd61024c7a12173b88c
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 
11.0.12101004
System Description: Ubuntu 22.04.4 LTS

Configured using:
 'configure --prefix=/home/phil/emacs/29.x.nc/usr/local
 --with-native-compilation=aot --with-x-toolkit=lucid --without-sound
 '--program-transform-name=s/^ctags$/ctags_emacs/''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP
X11 XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LC_MONETARY: en_NZ.UTF-8
  value of $LC_NUMERIC: en_NZ.UTF-8
  value of $LC_TIME: en_NZ.UTF-8
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte-compile cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
x multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 77322 5466)
 (symbols 48 7141 0)
 (strings 32 20482 1869)
 (string-bytes 1 617241)
 (vectors 16 15637)
 (vector-slots 8 327068 13857)
 (floats 8 29 46)
 (intervals 56 248 0)
 (buffers 984 11))

[recipe.sh (text/plain, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Cc: Jonas Bernoulli <jonas <at> bernoul.li>
Subject: Re: 29.2; user-init-file set to .../lisp/progmodes/compile.el.gz
Date: Fri, 01 Mar 2024 01:41:25 +1300

I should include the comments Jonas made previously in
the github discussion.

One was noting a successful workaround:

> I was able to "fix" it by adding (require 'compile) in
> early-init.el.

The other note was:

> I have a hunch that it might have something to do with
> the value of load-file-name somehow ending up being wrong
> at some point, because auto-compile changes it in a way
> / at a time, not expected by Emacs.

For clarity, auto-compile does not *explicitly* change
`load-file-name' (or reference it at all).


-Phil

Message #11 received at 69467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: jonas <at> bernoul.li, 69467 <at> debbugs.gnu.org
Subject: Re: bug#69467: 29.2;
 user-init-file set to .../lisp/progmodes/compile.el.gz
Date: Thu, 29 Feb 2024 15:08:40 +0200

> Cc: Jonas Bernoulli <jonas <at> bernoul.li>
> Date: Fri, 01 Mar 2024 01:23:50 +1300
> From: Phil Sainty <psainty <at> orcon.net.nz>
> 
> I recently encountered this undesirable side-effect when using the
> https://github.com/emacscollective/auto-compile library in conjunction
> with a byte-compiled init file.  The combination is reliably resulting
> in `user-init-file' being set to the .../lisp/progmodes/compile.el.gz
> path, with ensuing chaos (e.g. customized settings being written to
> that file -- I first became aware of this problem while using emacs -Q
> when it suddenly acquired some custom faces from my regular config as
> something loaded the compile library!).
> 
> The purpose of the auto-compile package is to ensure that .elc files
> are always up-to-date and loaded in preference to .el files.  I've been
> using it for many years and wasn't aware of having had any issues with
> it in the past, but I do not typically have a byte-compiled init.elc
> file.  The auto-compile code advises `load' and `require' (which does
> seem like it could present risks), however it seems so very odd to me
> that user-init-file could end up with this value for any reason that
> it seems like it might ultimately be an Emacs bug.
> 
> I raised it with the auto-compile maintainer (Jonas Bernoulli, CC'd)
> at https://github.com/emacscollective/auto-compile/issues/33 and we
> couldn't make sense of it at the time, so I'm escalating it here.
> 
> The attached bash shell recipe reproduces the issue in Emacs 29.
> I can reproduce it in all of Emacs 27, 28, 29, 30 (and not 26.3 or
> 25.3), but this recipe uses the --init-directory option which was
> added in 29.1.
> 
> (See attached script.)
> 
> The echo area in the final instance of Emacs should report the path to
> compile.el.gz (and re-running the final "touch init.el && ..." command
> will repeat that result each time).
> 
> 
> If I put (debug) at the top of compile.el.gz then I get the following
> backtrace, so we can see how/why compile.el is getting involved, but
> it just seems very wrong for that path to be able to end up being the
> user-init-file value.
> 
> 
> Debugger entered: nil
>    byte-code(...)
>    compilation-mode()
>    emacs-lisp-compilation-mode()
>    byte-compile-log-file()
>    byte-compile-from-buffer(#<buffer  *Compiler Input*>)
>    byte-compile-file("/tmp/autocomp/init.el")
>    auto-compile--byte-compile-file("/tmp/autocomp/init.el")
>    auto-compile-on-load("/tmp/autocomp/init" nil)
>    load <at> auto-compile("/tmp/autocomp/init" noerror nomessage)
>    apply(load <at> auto-compile ("/tmp/autocomp/init" noerror nomessage))
>    load("/tmp/autocomp/init" noerror nomessage)
>    startup--load-user-init-file(#f(compiled-function () #<bytecode 
> -0x54c765b3b165b77>) #f(compiled-function () #<bytecode 
> -0xe2e004ca56aeafc>) t)
>    command-line()
>    normal-top-level()

Are you sure load <at> auto-compile adheres to the protocol that is
described in the doc string of startup--load-user-init-file?  That is,
that this function is expected to set user-init-file to the name of
the init-file it loads?  IOW, step through or trace the code in
startup--load-user-init-file and see what happens there with the value
of user-init-file, and note that filename-function and
alternate-filename-function are expected to return the name of the
file they load.

> As it seems to have started in Emacs 27, my *guess* is that it's
> connected to the early-init.el system which was added in Emacs 27,
> but I've not dug any further at this stage.

Maybe it's related to early-init-file, or maybe it's related to a
thorough rewrite of startup--load-user-init-file which was needed to
support the early-init-file.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.