From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 29 07:24:40 2024 Received: (at submit) by debbugs.gnu.org; 29 Feb 2024 12:24:40 +0000 Received: from localhost ([127.0.0.1]:33828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rffSp-0005Kw-Nc for submit@debbugs.gnu.org; Thu, 29 Feb 2024 07:24:40 -0500 Received: from lists.gnu.org ([209.51.188.17]:46812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rffSk-0005Km-Dd for submit@debbugs.gnu.org; Thu, 29 Feb 2024 07:24:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rffSI-00034z-Vw for bug-gnu-emacs@gnu.org; Thu, 29 Feb 2024 07:24:07 -0500 Received: from smtp-4.orcon.net.nz ([60.234.4.59]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rffSE-00067e-1V for bug-gnu-emacs@gnu.org; Thu, 29 Feb 2024 07:24:05 -0500 Received: from [10.253.37.70] (port=35938 helo=webmail.orcon.net.nz) by smtp-4.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1rffS2-0000cT-Aj; Fri, 01 Mar 2024 01:23:53 +1300 Received: from ip-139-180-86-108.kinect.net.nz ([139.180.86.108]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Fri, 01 Mar 2024 01:23:50 +1300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_90c412279a91e942a1f6014b0cec7474" Date: Fri, 01 Mar 2024 01:23:50 +1300 From: Phil Sainty To: bug-gnu-emacs@gnu.org Subject: 29.2; user-init-file set to .../lisp/progmodes/compile.el.gz Message-ID: X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- Received-SPF: pass client-ip=60.234.4.59; envelope-from=psainty@orcon.net.nz; helo=smtp-4.orcon.net.nz X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: submit Cc: Jonas Bernoulli X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) --=_90c412279a91e942a1f6014b0cec7474 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed 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(#) 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@auto-compile("/tmp/autocomp/init" noerror nomessage) apply(load@auto-compile ("/tmp/autocomp/init" noerror nomessage)) load("/tmp/autocomp/init" noerror nomessage) startup--load-user-init-file(#f(compiled-function () #) #f(compiled-function () #) 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)) --=_90c412279a91e942a1f6014b0cec7474 Content-Transfer-Encoding: base64 Content-Type: text/plain; name=recipe.sh Content-Disposition: attachment; filename=recipe.sh; size=1626 IyBCQVNIIFNIRUxMIFJFQ0lQRSBCRUdJTlMKCiMgVGVtcCBjb25maWcgZGlyZWN0b3J5Lgpta2Rp ciAvdG1wL2F1dG9jb21wICYmIGNkIC90bXAvYXV0b2NvbXAKCiMgQWRkIE1FTFBBIHRvIHBhY2th Z2UtYXJjaGl2ZXMgZm9yIGluc3RhbGxpbmcgYXV0by1jb21waWxlLgpjYXQgPDwnRU9GJyA+aW5p dC5lbAooY3VzdG9tLXNldC12YXJpYWJsZXMKIDs7IGN1c3RvbS1zZXQtdmFyaWFibGVzIHdhcyBh ZGRlZCBieSBDdXN0b20uCiA7OyBJZiB5b3UgZWRpdCBpdCBieSBoYW5kLCB5b3UgY291bGQgbWVz cyBpdCB1cCwgc28gYmUgY2FyZWZ1bC4KIDs7IFlvdXIgaW5pdCBmaWxlIHNob3VsZCBjb250YWlu IG9ubHkgb25lIHN1Y2ggaW5zdGFuY2UuCiA7OyBJZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lLCB0 aGV5IHdvbid0IHdvcmsgcmlnaHQuCiAnKHBhY2thZ2UtYXJjaGl2ZXMgJygoIm1lbHBhIiAuICJo dHRwczovL21lbHBhLm9yZy9wYWNrYWdlcy8iKSkpKQooY3VzdG9tLXNldC1mYWNlcwogOzsgY3Vz dG9tLXNldC1mYWNlcyB3YXMgYWRkZWQgYnkgQ3VzdG9tLgogOzsgSWYgeW91IGVkaXQgaXQgYnkg aGFuZCwgeW91IGNvdWxkIG1lc3MgaXQgdXAsIHNvIGJlIGNhcmVmdWwuCiA7OyBZb3VyIGluaXQg ZmlsZSBzaG91bGQgY29udGFpbiBvbmx5IG9uZSBzdWNoIGluc3RhbmNlLgogOzsgSWYgdGhlcmUg aXMgbW9yZSB0aGFuIG9uZSwgdGhleSB3b24ndCB3b3JrIHJpZ2h0LgogKQpFT0YKCiMgSW5zdGFs bCBhdXRvLWNvbXBpbGUuCmVtYWNzIC0taW5pdC1kaXJlY3Rvcnk9IiQocHdkKSIgXAogIC1mIHBh Y2thZ2UtcmVmcmVzaC1jb250ZW50cyBcCiAgLS1ldmFsICIocGFja2FnZS1pbnN0YWxsICdhdXRv LWNvbXBpbGUpIiBcCiAgLWYgc2F2ZS1idWZmZXJzLWtpbGwtdGVybWluYWwKCiMgQ29uZmlndXJl IGNvbmZpZyB0byB1c2UgYXV0by1jb21waWxlLgojIChuLmIuIHRoZXJlJ3MgYSBzaGVsbCBjb21t YW5kIHN1YnN0aXR1dGlvbiBpbiB0aGlzIHRvIGdldAojIHRoZSBwYWNrYWdlIGRpcmVjdG9yeSBu YW1lLikKY2F0IDw8RU9GID5lYXJseS1pbml0LmVsCjs7IGVhcmx5LWluaXQuZWw6Cjs7IFJlY29t cGlsZSAuZWxjIGZpbGVzIGF1dG9tYXRpY2FsbHkgd2hlbmV2ZXIgbmVjZXNzYXJ5LgooYWRkLXRv LWxpc3QgJ2xvYWQtcGF0aCAoZXhwYW5kLWZpbGUtbmFtZQogICAgICAgICAgICAgICAgICAgICAg ICAgIiQobHMgLWQgZWxwYS9hdXRvLWNvbXBpbGUtKikiCiAgICAgICAgICAgICAgICAgICAgICAg ICB1c2VyLWVtYWNzLWRpcmVjdG9yeSkpCihyZXF1aXJlICdhdXRvLWNvbXBpbGUpCihhdXRvLWNv bXBpbGUtb24tc2F2ZS1tb2RlIDEpCihhdXRvLWNvbXBpbGUtb24tbG9hZC1tb2RlIDEpCkVPRgoK IyBCeXRlLWNvbXBpbGUgaW5pdC5lbAplbWFjcyAtLWJhdGNoIC1mIGJhdGNoLWJ5dGUtY29tcGls ZSBpbml0LmVsCgojIFVwZGF0ZSB0aGUgdW5jb21waWxlZCBmaWxlLCBzdGFydCBFbWFjcywgYW5k IHJlcG9ydCB1c2VyLWluaXQtZmlsZS4KdG91Y2ggaW5pdC5lbCAmJiBlbWFjcyAtLWluaXQtZGly ZWN0b3J5PSIkKHB3ZCkiIFwKICAtLWV2YWw9IihtZXNzYWdlIFwiJXNcIiB1c2VyLWluaXQtZmls ZSkiCgojIEJBU0ggU0hFTEwgUkVDSVBFIEVORFMK --=_90c412279a91e942a1f6014b0cec7474-- From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 29 07:42:04 2024 Received: (at submit) by debbugs.gnu.org; 29 Feb 2024 12:42:04 +0000 Received: from localhost ([127.0.0.1]:33841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rffjg-0008Ur-CZ for submit@debbugs.gnu.org; Thu, 29 Feb 2024 07:42:04 -0500 Received: from lists.gnu.org ([209.51.188.17]:57508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rffje-0008Uk-Hx for submit@debbugs.gnu.org; Thu, 29 Feb 2024 07:42:03 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rffj9-00038c-Gq for bug-gnu-emacs@gnu.org; Thu, 29 Feb 2024 07:41:33 -0500 Received: from smtp-4.orcon.net.nz ([60.234.4.59]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rffj6-0002Jc-UH for bug-gnu-emacs@gnu.org; Thu, 29 Feb 2024 07:41:30 -0500 Received: from [10.253.37.70] (port=59777 helo=webmail.orcon.net.nz) by smtp-4.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1rffj3-0002GA-9N; Fri, 01 Mar 2024 01:41:25 +1300 Received: from ip-139-180-86-108.kinect.net.nz ([139.180.86.108]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Fri, 01 Mar 2024 01:41:25 +1300 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 01 Mar 2024 01:41:25 +1300 From: Phil Sainty To: bug-gnu-emacs@gnu.org Subject: Re: 29.2; user-init-file set to .../lisp/progmodes/compile.el.gz In-Reply-To: References: Message-ID: <2da17ec1bfd0501265f24b3950c093a8@webmail.orcon.net.nz> X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- Received-SPF: pass client-ip=60.234.4.59; envelope-from=psainty@orcon.net.nz; helo=smtp-4.orcon.net.nz X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.7 (-) X-Debbugs-Envelope-To: submit Cc: Jonas Bernoulli X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 29 08:11:39 2024 Received: (at 69467) by debbugs.gnu.org; 29 Feb 2024 13:11:39 +0000 Received: from localhost ([127.0.0.1]:33870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rfgCJ-0000rY-Bb for submit@debbugs.gnu.org; Thu, 29 Feb 2024 08:11:39 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58026) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rfgCE-0000rH-62 for 69467@debbugs.gnu.org; Thu, 29 Feb 2024 08:11:37 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rfg9Y-0001MX-OV; Thu, 29 Feb 2024 08:08:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WBn2x5Fkh+9EuEDbZdKK6rDJoIrcG6md6v5y4g6jar8=; b=YT02yDOqBTMn 8sbVDEhnLa23T5Dx7MHTvuVhoJgYkOFa+IvcEgEE0qWhnBJ3FvUxJEVXspnwpKH3JlKjUW1VC5kJ4 2SBSIDVBBz7VxUc4b0WyLvioufHZ0JAnlr3wymhNr3S3zSQITJbMWp3206IOB+Qogs5cD99lZR+6s /xuL12bwd+PdXvVUNR9VLy5K//QuEN2KeyLrOHAZ9wdM98sxqKsS9HGBPYU86vyPqYLjoPELAw2bH vpknOhGll9NlRwwFnBY7nqKHJMNGTgisqonbPyjAqQBz9B0vs9DMoNr4hzngU801rPEkY/xG+UIXO FWT1kCuJlksZHwxj7wMAew==; Date: Thu, 29 Feb 2024 15:08:40 +0200 Message-Id: <86msrjs9if.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-Reply-To: (message from Phil Sainty on Fri, 01 Mar 2024 01:23:50 +1300) Subject: Re: bug#69467: 29.2; user-init-file set to .../lisp/progmodes/compile.el.gz References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69467 Cc: jonas@bernoul.li, 69467@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Jonas Bernoulli > Date: Fri, 01 Mar 2024 01:23:50 +1300 > From: Phil Sainty > > 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(#) > 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@auto-compile("/tmp/autocomp/init" noerror nomessage) > apply(load@auto-compile ("/tmp/autocomp/init" noerror nomessage)) > load("/tmp/autocomp/init" noerror nomessage) > startup--load-user-init-file(#f(compiled-function () # -0x54c765b3b165b77>) #f(compiled-function () # -0xe2e004ca56aeafc>) t) > command-line() > normal-top-level() Are you sure load@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.