From unknown Sun Aug 10 09:07:44 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#79124 <79124@debbugs.gnu.org> To: bug#79124 <79124@debbugs.gnu.org> Subject: Status: emacs -Q doesn't give me a clean slate Reply-To: bug#79124 <79124@debbugs.gnu.org> Date: Sun, 10 Aug 2025 16:07:44 +0000 retitle 79124 emacs -Q doesn't give me a clean slate reassign 79124 emacs submitter 79124 Paul Eggert severity 79124 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 29 19:59:38 2025 Received: (at submit) by debbugs.gnu.org; 29 Jul 2025 23:59:38 +0000 Received: from localhost ([127.0.0.1]:37172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uguEL-0007fp-KM for submit@debbugs.gnu.org; Tue, 29 Jul 2025 19:59:38 -0400 Received: from lists.gnu.org ([2001:470:142::17]:39842) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uguEJ-0007fE-C1 for submit@debbugs.gnu.org; Tue, 29 Jul 2025 19:59:36 -0400 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 1uguEB-0000TD-0Q for bug-gnu-emacs@gnu.org; Tue, 29 Jul 2025 19:59:28 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uguE9-0003ix-6o for bug-gnu-emacs@gnu.org; Tue, 29 Jul 2025 19:59:26 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id C7CFF3C010841 for ; Tue, 29 Jul 2025 16:59:23 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id B-aeaZNQtigp for ; Tue, 29 Jul 2025 16:59:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id A15323C01084A for ; Tue, 29 Jul 2025 16:59:23 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu A15323C01084A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1753833563; bh=Ok2xdKc7vVZfONpPzAy1WQ0eKpTPeBUrAVI+xQTZkbI=; h=Message-ID:Date:MIME-Version:To:From; b=Uueiy/YhZ/OP+gsktv6kdzT1oVyqOMoeESNkI22kDlauupvWd/IL+0RSaLp+Kkkfm S6qmhxUfiXBOd1gpp8AU6a447VDCNLku7j6CDnu1y75dduS7ONROV6WVqapwY2QAC7 p9zn60qyCPNnNex/CUGpeg6xvsrpz8E7iKsWNSG8VJIA76nhe4hYif8yW09leXHguP mCoP2nnoZiAJiYFADoXw/wgvDpX1eLx2RiaZxzdNzUvTupuTNA4SYPSG1HFAnohPnS UY66lZgakcWb0Dnc1meNDFw+bsTDGtOQSTo+O+IixCqKh5yrMPu4zAjVd/Q9sNYpep UG4XnDjx+Ausw== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id EIU22ODvG1RT for ; Tue, 29 Jul 2025 16:59:23 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 7ABC33C010841 for ; Tue, 29 Jul 2025 16:59:23 -0700 (PDT) Message-ID: Date: Tue, 29 Jul 2025 16:59:23 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Emacs bug reports and feature requests From: Paul Eggert Subject: emacs -Q doesn't give me a clean slate Organization: UCLA Computer Science Department Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=131.179.128.66; envelope-from=eggert@cs.ucla.edu; helo=mail.cs.ucla.edu X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit 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: -0.0 (/) Over the years Emacs has come slurp more and more files from the user's home directory, which is fine except that 'emacs -Q' is supposed to suppress this sort of thing, partly to help debugging so that one can easily have a clean Emacs to test with. Unfortunately, nowadays 'emacs -Q' now has some questionable accesses to configuration files or caches. I did an "cd /tmp" followed by an "strace emacs -Q -nw" using Emacs master (on Fedora 42) where I immediately typed C-x C-c to exit, and found that Emacs accessed or attempted to access the following files under my home directory. -Q should disable these accesses; or if -Q is not the right way to do that, there should be an easy way to tell Emacs "start with a clean slate; don't access any of my startup configuration or cache or whatever". .abbrev_defs .emacs.d .emacs.d/ .emacs.d/./ .emacs.d/abbrev_defs .emacs.d/auto-save-list/.saves-67042-penguin.cs.ucla.edu~ .emacs.d/eln-cache/ .emacs.d/eln-cache/31.0.50-6ea53a16/ .emacs.d/eln-cache/31.0.50-6ea53a16/ansi-color-75eac800-a71f27cf.eln .emacs.d/eln-cache/31.0.50-6ea53a16/ansi-osc-b447f6a8-8febe2b9.eln .emacs.d/eln-cache/31.0.50-6ea53a16/byte-opt-9c5f25f5-7cc5ddb7.eln .emacs.d/eln-cache/31.0.50-6ea53a16/bytecomp-12882072-8edd60a1.eln .emacs.d/eln-cache/31.0.50-6ea53a16/cl-lib-8b938900-a571fbf6.eln .emacs.d/eln-cache/31.0.50-6ea53a16/cl-loaddefs-310c8015-a1d7aa30.eln .emacs.d/eln-cache/31.0.50-6ea53a16/comint-faef15ad-bfa1fb2f.eln .emacs.d/eln-cache/31.0.50-6ea53a16/comp-common-6e17f702-933f2808.eln .emacs.d/eln-cache/31.0.50-6ea53a16/comp-run-a15747ee-efc134fc.eln .emacs.d/eln-cache/31.0.50-6ea53a16/compile-91e1c2a0-9cbeba37.eln .emacs.d/eln-cache/31.0.50-6ea53a16/gv-e0cf7478-71e25e63.eln .emacs.d/eln-cache/31.0.50-6ea53a16/ring-bff0b981-036e8192.eln .emacs.d/eln-cache/31.0.50-6ea53a16/rx-627d8c83-9aae5e83.eln .emacs.d/eln-cache/31.0.50-6ea53a16/subr-x-02dfef32-97626417.eln .emacs.d/eln-cache/31.0.50-6ea53a16/text-property-search-db1383f6-03526671.eln .emacs.d/eln-cache/31.0.50-6ea53a16/time-date-40951a48-4999dc2b.eln .terminfo From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 08:17:02 2025 Received: (at 79124) by debbugs.gnu.org; 30 Jul 2025 12:17:02 +0000 Received: from localhost ([127.0.0.1]:40131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uh5jx-0004th-JV for submit@debbugs.gnu.org; Wed, 30 Jul 2025 08:17:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52432) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uh5ju-0004t3-Pg for 79124@debbugs.gnu.org; Wed, 30 Jul 2025 08:16:59 -0400 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 1uh5jn-0003dm-Vp; Wed, 30 Jul 2025 08:16:51 -0400 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=j7dZuJJ5gZ6/K1+8npsi8rppz+QdzKTZhorzdAwZ9/Y=; b=fXP3AaM97rLX 1wawYRYTk763Jx87i5aJEjjTJRZL6kDkfQ6HUQORdQJ9tSCpdaYayNSHOBdbyKRWhcc9rODoCks/x D5k0yEAcuLHA9z+uQy7b5+v+JktTb4MQL+AeMYn9TfQ+hev0zIsQtzESIKTi8Dji1/vyyUqNJ9Euk VqRAcO3LqgtPEl4wJ6SjNDWc9lWvfy05D9Ot3RmLm1PSHV+xAzp6ssLnaZDZHIcm45ls7DLf3jCQK QUkZAknU4Z7w9a4GwmaT9WE6bkYpXvwYLZCmJ/ySyxR0LBflQYgoEG95AYnVYT+3W373SD4iyNlMe vvr8Lh8t/DkFQvDW5IuEOQ==; Date: Wed, 30 Jul 2025 15:15:49 +0300 Message-Id: <868qk5x4ay.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert , Richard Stallman In-Reply-To: (message from Paul Eggert on Tue, 29 Jul 2025 16:59:23 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: 79124@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 (---) > Date: Tue, 29 Jul 2025 16:59:23 -0700 > From: Paul Eggert > > Over the years Emacs has come slurp more and more files from the user's > home directory, which is fine except that 'emacs -Q' is supposed to > suppress this sort of thing, partly to help debugging so that one can > easily have a clean Emacs to test with. > > Unfortunately, nowadays 'emacs -Q' now has some questionable accesses to > configuration files or caches. I did an "cd /tmp" followed by an "strace > emacs -Q -nw" using Emacs master (on Fedora 42) where I immediately > typed C-x C-c to exit, and found that Emacs accessed or attempted to > access the following files under my home directory. -Q should disable > these accesses; or if -Q is not the right way to do that, there should > be an easy way to tell Emacs "start with a clean slate; don't access any > of my startup configuration or cache or whatever". > > .abbrev_defs > .emacs.d > .emacs.d/ > .emacs.d/./ > .emacs.d/abbrev_defs This is because we load abbrevs at startup, even under -Q. That was added in Nov 2001: commit ac3186fd96de9332bbeb4c7bf1f7ac66de26752a Author: Richard M. Stallman AuthorDate: Sun Nov 11 01:53:31 2001 +0000 Commit: Richard M. Stallman CommitDate: Sun Nov 11 01:53:31 2001 +0000 (command-line): Read standard abbrev file (abbrev-file-name), if it exists. I couldn't find any discussion why this was added. Perhaps Richard remembers why he added that, and whether doing this under -Q was on purpose or an omission? > .emacs.d/auto-save-list/.saves-67042-penguin.cs.ucla.edu~ This is because we want to support recovering crashed sessions, even with -Q. Not sure this is wrong. > .emacs.d/eln-cache/ > .emacs.d/eln-cache/31.0.50-6ea53a16/ > .emacs.d/eln-cache/31.0.50-6ea53a16/ansi-color-75eac800-a71f27cf.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/ansi-osc-b447f6a8-8febe2b9.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/byte-opt-9c5f25f5-7cc5ddb7.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/bytecomp-12882072-8edd60a1.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/cl-lib-8b938900-a571fbf6.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/cl-loaddefs-310c8015-a1d7aa30.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/comint-faef15ad-bfa1fb2f.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/comp-common-6e17f702-933f2808.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/comp-run-a15747ee-efc134fc.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/compile-91e1c2a0-9cbeba37.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/gv-e0cf7478-71e25e63.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/ring-bff0b981-036e8192.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/rx-627d8c83-9aae5e83.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/subr-x-02dfef32-97626417.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/text-property-search-db1383f6-03526671.eln > .emacs.d/eln-cache/31.0.50-6ea53a16/time-date-40951a48-4999dc2b.eln These are natively-compiled Lisp packages. I'm guessing that, since you've started a -nw session, Emacs needed to load the support library for the terminal you are using, which triggered the JIT native compilation of that library and all the libraries it depends on. So this is normal, and has nothing to do with -Q: Emacs must load the Lisp packages needed for its operation. > .terminfo I guess this is from some curses library, not from Emacs per se. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 10:11:28 2025 Received: (at 79124) by debbugs.gnu.org; 30 Jul 2025 14:11:28 +0000 Received: from localhost ([127.0.0.1]:41645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uh7Wh-0004Gv-DN for submit@debbugs.gnu.org; Wed, 30 Jul 2025 10:11:28 -0400 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:44255) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uh7We-0004GX-M1 for 79124@debbugs.gnu.org; Wed, 30 Jul 2025 10:11:26 -0400 Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4589968e001so4959005e9.0 for <79124@debbugs.gnu.org>; Wed, 30 Jul 2025 07:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753884678; x=1754489478; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=VcLBGAZhHf7h3iZmDCtb+Ht4Vz56JoOLxvjH/wtzxbQ=; b=InSIwRO0VV2wVwF3yL2NRS71glzBkdrY3/YmOf4p35Jm2wMRo+Z73RJJrkPVsl0Zm1 4y3gGIg+eE33uMd/NLbgbbBW4/FPdixiv8tX2uoo+lQ5OUNAwD0KaMHeenOR5JiI0hSD M4RP0WHyUPhlvXGXLpN77SUgFgxQrm6ZNl/fwALcuPugvGwDUreYhSG3EVatIs9tY3Q7 Kva/a7f00rsdAMaooskrTkRRVOV8q8slLF83MmPelGVEX5bnUQ00PjZLzfXRKhUy6ok4 8x53pP90/4zsVAs+YZRFrFRFyj6tO9fphaRPqnPImNZu8wiAq+b6F/OKpQ1ZTbROxH1L 71qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753884678; x=1754489478; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VcLBGAZhHf7h3iZmDCtb+Ht4Vz56JoOLxvjH/wtzxbQ=; b=Ctbsiksf7jfeaGauxFyMIbCgjxLOCuC8KcsCYK5CHVngo9/rMTs3x9uQQ6cseSQIHr /9lmWImOTM6IEBeUWVA41hzDcLwhltOO7XsSsbnIJJEF5mhjL1rvHdPPEJfDVqE1Ugeg wC+QBwhaK90KiY92T32aYF2RIoM5Csz9zDCO5IRaEsQAPVWZjdQyovxAWYDIvWxDNjsm /ru4t3XTNB3/ibwx5Ppwl9s0sNTawRKRQ/IVg3jfeLV5vYFSdbZ3wIiswong4T0j0otI UAFXQ/U2coBhKpbuT0g1mCikEQQeZVZDbXQ/MizKdmiaWUAP9apoOC3gfzjIRs6xhF43 0PVg== X-Forwarded-Encrypted: i=1; AJvYcCUZ3l8ay3X753ymztNBG1EfbaVxpk+sNV2nL0bVsZHqAI47jxcXMY+KC9VUXf+xxLeyMeISfw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywd5GI6ujslJIaosM4XrB7NjvxFAw0ps+xioqo/dFV/dy9RSx0T 0EIYb5qytCwJTTG/B+aXXYbEfyg2AZc1lUIqXLHCv4lrgGgV72fQwvv0DSY8Xw== X-Gm-Gg: ASbGncvvkbegJmIhZFMpI1hAwRjmwy6q9KlmhyyW1w3D3pnkVyry9d0FqUnJzMegUSn MBIc+Xv1kgup16GymvIqaVdyeNCDchO5GGGwSvUzg3pUW8tyBTlCvDOEPaR/vpB54RqjDfl+djx McJ3MiCB2BLGgEdv2NYHaAiPfNMWldDXY8LMQfOGxKqI0ylXmPr1y0gotZz9s75iGdmfxMcsUZx AeVZ3hVW4OJ8XppyrNdotO74elzJag1bexIVYqN1geg3yhCfEoQG2knuT416xXZa0IiW5gYzAsg w7u+hN0G7UOCYn1iGqnQijtuXsN2u9E8k1gX3FmD1i0zXXzOxpG5gol9maPA3+lgCa51ODs+gJe eGAAXisAlcg== X-Google-Smtp-Source: AGHT+IH8jppHcXUP86ENaTgJUjlaHFEB88M3JVsbHJLI8i//3F0lSEHTeveB0YnSidTfXFpXS3n+CA== X-Received: by 2002:a05:6000:288a:b0:3b7:8146:4640 with SMTP id ffacd0b85a97d-3b79503579dmr2783218f8f.56.1753884677777; Wed, 30 Jul 2025 07:11:17 -0700 (PDT) Received: from rltb ([2a01:e0a:3f3:fb51:d168:7163:fc6b:404b]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b788f5f255sm10046961f8f.13.2025.07.30.07.11.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Jul 2025 07:11:16 -0700 (PDT) From: Robert Pluim To: Eli Zaretskii Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate In-Reply-To: <868qk5x4ay.fsf@gnu.org> References: <868qk5x4ay.fsf@gnu.org> Date: Wed, 30 Jul 2025 16:11:15 +0200 Message-ID: <87o6t1ahvg.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: Paul Eggert , 79124@debbugs.gnu.org, Richard Stallman 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: -1.0 (-) >>>>> On Wed, 30 Jul 2025 15:15:49 +0300, Eli Zaretskii said: >> Date: Tue, 29 Jul 2025 16:59:23 -0700 >> From: Paul Eggert >>=20 >> Over the years Emacs has come slurp more and more files from the use= r's=20 >> home directory, which is fine except that 'emacs -Q' is supposed to= =20 >> suppress this sort of thing, partly to help debugging so that one ca= n=20 >> easily have a clean Emacs to test with. >>=20 >> Unfortunately, nowadays 'emacs -Q' now has some questionable accesse= s to=20 >> configuration files or caches. I did an "cd /tmp" followed by an "st= race=20 >> emacs -Q -nw" using Emacs master (on Fedora 42) where I immediately= =20 >> typed C-x C-c to exit, and found that Emacs accessed or attempted to= =20 >> access the following files under my home directory. -Q should disabl= e=20 >> these accesses; or if -Q is not the right way to do that, there shou= ld=20 >> be an easy way to tell Emacs "start with a clean slate; don't access= any=20 >> of my startup configuration or cache or whatever". >>=20 >> .abbrev_defs >> .emacs.d >> .emacs.d/ >> .emacs.d/./ >> .emacs.d/abbrev_defs We sometimes also read from .emacs.d/network-security.data under -Q, which can be annoying when testing TLS code. I can=CA=BCt remember exactly the cause, since I=CA=BCve long switched to "HOME=3D/tmp/emacs src/emacs -Q= ". Robert --=20 From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 11:30:02 2025 Received: (at 79124) by debbugs.gnu.org; 30 Jul 2025 15:30:02 +0000 Received: from localhost ([127.0.0.1]:42009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uh8kj-0000iE-PB for submit@debbugs.gnu.org; Wed, 30 Jul 2025 11:30:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38010) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uh8kh-0000hl-0B for 79124@debbugs.gnu.org; Wed, 30 Jul 2025 11:30:00 -0400 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 1uh8kb-0002FG-3u; Wed, 30 Jul 2025 11:29:53 -0400 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=F3ogfCLKS/7UST88R1F6IbCA8ESVTNNWR4VUz5i/QXo=; b=nWAcYpNRe0fX m/AMMhdPaEuGTHabsEnDWKoss6GQ/BoX9nuO6HeOHQfo9v8uKzXSW1ZSEyqw1jy68h3+HzxgjSI1U CGEhZX+X0crNI0bkFxZvR6z4Y2sdyla+Xi0ur8ulkIiU2xm3AO3H8jiHpRuWrqTsClqRAayKu9lO9 pTrKjD31ivqsj+YDbbqWN/fh1NPdwIFk3FYhTDxx/Ca2eYcslaX9mN1pC1F1lNWq2oAamk2dUYvQf WiD1HWhyDwi7ltBYYx7Sa8d7FiaqsbQPF7qcgLM8p714k6uOuauwW8kdMI8pryRVgqk0fdrSqlT3q 4g9dtCR3PGfI7E4CWJeoWA==; Date: Wed, 30 Jul 2025 18:29:40 +0300 Message-Id: <86tt2tvgrf.fsf@gnu.org> From: Eli Zaretskii To: Robert Pluim In-Reply-To: <87o6t1ahvg.fsf@gmail.com> (message from Robert Pluim on Wed, 30 Jul 2025 16:11:15 +0200) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: eggert@cs.ucla.edu, 79124@debbugs.gnu.org, rms@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 (---) > From: Robert Pluim > Cc: Paul Eggert , Richard Stallman , > 79124@debbugs.gnu.org > Date: Wed, 30 Jul 2025 16:11:15 +0200 > > We sometimes also read from .emacs.d/network-security.data under -Q, Not at startup time, right? You are talking about calling some network-related APIs. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 11:33:36 2025 Received: (at 79124) by debbugs.gnu.org; 30 Jul 2025 15:33:36 +0000 Received: from localhost ([127.0.0.1]:42034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uh8oC-000101-0Z for submit@debbugs.gnu.org; Wed, 30 Jul 2025 11:33:36 -0400 Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:50391) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uh8oA-0000zk-31 for 79124@debbugs.gnu.org; Wed, 30 Jul 2025 11:33:34 -0400 Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-3a575a988f9so3795212f8f.0 for <79124@debbugs.gnu.org>; Wed, 30 Jul 2025 08:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753889607; x=1754494407; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=Ijyln7/Y4Xwwglr9xou4p8X2uZEuuIM1pzAc+tgzSSc=; b=EMnR4nUDsLBuWYyzhmlDjm1833P61rMG+huq9aED7X9gWrgZ5wZ+iB9qxuUuC4JwaD Il1T7WDRw0b1404I+1nqYmkX26r8kY4Ec7AKeiB5eZDz7X6ke+iZ2n3pULeWE02wgzdd 4wgU4Hyza+AAHOKIlWWm0XeUgitZ3C7ltC0wkG/vh4zoDb/Wf/9RhB3ZI4uxWGo3NjyU q9qhPBMy+rzXt2U0Iz83R0qv15ID0IJZgWe2O/oCufmu0QnVxTYsPLVHg5NyoFLoqTLK nKaSqJ0yIHHcexCT5WpsLJtwzwMaXGhdiZHZ3yLoe8ZtFpng/nK9qjrtX8JiLkgWKjZz 9HJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753889607; x=1754494407; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ijyln7/Y4Xwwglr9xou4p8X2uZEuuIM1pzAc+tgzSSc=; b=L5LnzW8IA7PFovUbW7sFW+1GFvEzNZgWAcERFALWkq7+AC4ny4fXPL0x1mZ9ATA+HZ 8yQLHh7ohkIOoV5vRmkm9JjRZ/fMCpQyuMEGvkf25FM+2V+LQ+H9RqqM07kl8Ao/ru00 mJawdOdgQ3y7Des7+hN2lNsER3xihBLHtohUoygUY8esqzg+c+RvwxdoF2H0PDPUAfIk KR2GVMXOl1WqrqAv2H3xzWWdtEfynDq65+8dK0eYFtY9ulntjHOlJkUTW20FuXLxTig2 YCMw6HkeZpw9hX5vL+5QcmmH3hSE8PzsxymkN4C6KerS6e4mtLi8uN7VvNLNheRx7I3Y 9ygw== X-Forwarded-Encrypted: i=1; AJvYcCU03TZ5S6TnosVOZ0Voya7DE0j0Abs3iQZ30rzZa0sbbeQTJ0yHipA2S51iJGpSXn1/dz+VDg==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yyn4xz0chQlhZPff4Wjn8IDuX6BiLdmAZuAPQWNW1z1VFzMEa9q 642TxFOVD7okHbyabQXY4KDv7O0EiuEWH9FcK1S9eIoqBuHQ+A2u7pt6d5gPeA== X-Gm-Gg: ASbGnctb8NrOHmOGFslXixxSGXGynjn6fhfCry5z0/7jIXKXTzeE/Ux726U3bIJEbJw CC1+GXjRn3B+zyFf4fGx1TMj9+r11oMvTliqkxvMJ+HPIbbcZKBkT32xpjxb95iRymXjiuN2w2S 6tXad7TrZZqwYQw0B+o53sAiJ4V97FJqTDNOzycbD+fNvXhwDb2qIiUo0Z4FyhQI3zoqizygmiK FN2/+JmcavcHPh3wgQT7aKVBWgjE87Lu8ikrZha4yr6c6okf6qqQ6mNcxkMLAH+c+6K4/a1kraE yurajfhO9jf1Z3PckjGLsaHaUeT5O8mco9e7O8YyiX5Qh6sEniSZ5Q2yi+4gMXz8dVcsac5Vx/1 tVfX1W7V/Mw== X-Google-Smtp-Source: AGHT+IGccjp3/OZFojcvDmHo7OQ6CCI2WFn9RO44UkWu2NMYnUgRyWL3s9C+qRBjG9bRXdksk6bH1g== X-Received: by 2002:a05:6000:420a:b0:3b4:65d4:8e27 with SMTP id ffacd0b85a97d-3b794ff352cmr2891203f8f.29.1753889607356; Wed, 30 Jul 2025 08:33:27 -0700 (PDT) Received: from rltb ([2a01:e0a:3f3:fb51:d168:7163:fc6b:404b]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b778f0c477sm15809484f8f.58.2025.07.30.08.33.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Jul 2025 08:33:26 -0700 (PDT) From: Robert Pluim To: Eli Zaretskii Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate In-Reply-To: <86tt2tvgrf.fsf@gnu.org> References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> Date: Wed, 30 Jul 2025 17:33:26 +0200 Message-ID: <87jz3pae2h.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: eggert@cs.ucla.edu, 79124@debbugs.gnu.org, rms@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: -1.0 (-) >>>>> On Wed, 30 Jul 2025 18:29:40 +0300, Eli Zaretskii said: >> From: Robert Pluim >> Cc: Paul Eggert , Richard Stallman , >> 79124@debbugs.gnu.org >> Date: Wed, 30 Jul 2025 16:11:15 +0200 >>=20 >> We sometimes also read from .emacs.d/network-security.data under -Q, Eli> Not at startup time, right? You are talking about calling some Eli> network-related APIs. Right. But it=CA=BCs still surprising that Emacs reads from ~/.emacs.d when -Q is specified. Basically it happens whenever `nsm-verify-connection' calls `nsm-host-settings'. We could add a check for "-Q" there. Robert --=20 From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 12:04:15 2025 Received: (at 79124) by debbugs.gnu.org; 30 Jul 2025 16:04:15 +0000 Received: from localhost ([127.0.0.1]:42191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uh9Hr-0002zN-4e for submit@debbugs.gnu.org; Wed, 30 Jul 2025 12:04:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56198) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uh9Ho-0002z2-A8 for 79124@debbugs.gnu.org; Wed, 30 Jul 2025 12:04:13 -0400 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 1uh9Hh-0008Bs-Qi; Wed, 30 Jul 2025 12:04:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=tZ7L0sGWQIQiy8DQpFiea1nVZcFpxvgtv73oZdpXl/w=; b=Dwa8Wn0yWzpGAl6fIWIJ TAmsNA8OoSbw3caLJhN09dlswSZ3J84wpA8k5w3r/RhxeXcWtUwW7uG2GUJqJ5+DkZJ5ZHrNX70LM nlFnZBgmJ++Vo39OcPY8JjIWXtUdFRmXSdaCZn2SQwrVaX6HA7Fyf8F92zmcEwpoLnwDhHw26watm ChpS7GR4CVG4zUqs+EGcmnF2HgkTwgjd5w8rdCYVaAN+hnwzitboyINuByZnKJlCmEkRYZNA3+htw lS5uSU/6C7PQ/jnvT9YSqVR6REZpYmfkOe049Hv68WJFAYF7k6hR18TxTTLB5wi6f+Ewfw7aJODbc xG+XM+NnLzeLtw==; Date: Wed, 30 Jul 2025 19:03:25 +0300 Message-Id: <86seidvf76.fsf@gnu.org> From: Eli Zaretskii To: Robert Pluim In-Reply-To: <87jz3pae2h.fsf@gmail.com> (message from Robert Pluim on Wed, 30 Jul 2025 17:33:26 +0200) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: eggert@cs.ucla.edu, 79124@debbugs.gnu.org, rms@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 (---) > From: Robert Pluim > Cc: eggert@cs.ucla.edu, rms@gnu.org, 79124@debbugs.gnu.org > Date: Wed, 30 Jul 2025 17:33:26 +0200 > > >>>>> On Wed, 30 Jul 2025 18:29:40 +0300, Eli Zaretskii said: > > >> From: Robert Pluim > >> Cc: Paul Eggert , Richard Stallman , > >> 79124@debbugs.gnu.org > >> Date: Wed, 30 Jul 2025 16:11:15 +0200 > >> > >> We sometimes also read from .emacs.d/network-security.data under -Q, > > Eli> Not at startup time, right? You are talking about calling some > Eli> network-related APIs. > > Right. But itʼs still surprising that Emacs reads from ~/.emacs.d when > -Q is specified. > > Basically it happens whenever `nsm-verify-connection' calls > `nsm-host-settings'. We could add a check for "-Q" there. OTOH, it's quite annoying to type the same responses to the NSM prompts when trying stuff in "emacs -Q". There is "emacs -D", which perhaps could be more "pristine". Patches welcome. That said, these options are of interest only to Emacs hackers. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 12:23:34 2025 Received: (at 79124) by debbugs.gnu.org; 30 Jul 2025 16:23:34 +0000 Received: from localhost ([127.0.0.1]:42248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uh9aX-000482-N5 for submit@debbugs.gnu.org; Wed, 30 Jul 2025 12:23:34 -0400 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:45255) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uh9aU-00047h-9I for 79124@debbugs.gnu.org; Wed, 30 Jul 2025 12:23:31 -0400 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-4561607166aso7909115e9.2 for <79124@debbugs.gnu.org>; Wed, 30 Jul 2025 09:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753892604; x=1754497404; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=HEV5mHoL7uXXEsiQONwF5jTsi1XRC2XQ002egqbAx2k=; b=F2sjhu05/DY8ys5FMA6kM5mtStRrX/UgNHngYVNRFi6WU+FKopwu/HsuLC3EarOoEr fz5bo23V00tJMOgHpF35WWJhNaMPK7DX2mMJBbcwwRl7oqLX3Eeui8fFlavs8MVUNcxc xrVtePGXlymMMs0MwhRMfwj5qeeULmWBShLW3WLxFdkgXrcWytpyiYqvF0mYHjEkwPaB NqB93LExJELaKArf/2WwlP0YYc2W0UCo0HwgVHxgPA0IJrEJ2cEo/X6rrRkYkhJKDUGb YUBd5FQ83DBTeLYXRbq8bUIWAfaepWPCHg1FJNy2EB/oe2j9GaKoCpL2VxDvZUsTM+rW SFfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753892604; x=1754497404; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HEV5mHoL7uXXEsiQONwF5jTsi1XRC2XQ002egqbAx2k=; b=T79BUfCsZQf/WR8aBxcs3hllBKtAFO638xvB1hV4Dl0kkA8ELNRfiNnH5QTLkVMoc5 hrbr7k7Wn8fr52mJGVZ0ZLxImX3tl6qm246gkY49jSP95t3ArRwNy5rzvm50v6SzFEoO vAgedon+62EWi3YBX8vmD8LGAe0PXOsUjKgkkmmEjBuUxn2qascY3FYQOKNuHrxxLk0A 4uQIVMH403irDEdLwqbOA44xd43YwpegFHhSdBw0pXnTYNjTsMMlHKTYLcqAJQKNJK/w VCVTuog0wsHMBo+iFi7TQsMlFE6vtBWMGHER5bU5czqcBkzcl/vSFvRFY/cG6mJJpoxZ tYHQ== X-Forwarded-Encrypted: i=1; AJvYcCW72t69BjUNSNnIga1Yt4NM2J9Yfy6pv+nisE85Y7j/8OuZY+iTG2OF2HM4GDR8CGKxR0hFgQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzrVcBZfo5Iz/h54MXRz9eBMg5YGt4Y3l8R1PUjDiyuafMpxllh JLCEsEQp6lbprgimu5Ds2rasTTb5dlajurbnMzMx2JWk3vU4WxBOnVQwa37zmQ== X-Gm-Gg: ASbGncu1Y8RhS/3b4PmlAvHxyhRasGySvsCa1BmvWWFSZznlkI3Qm6lHd/X8X3yWlV9 sKfdqwaCLnKqlZHGJ3TxgygEm1iWfbpvlDBP0nbySQ1SVViqcb/UgzvT9OHpSJ2kd6HLP3yy3Kj EX8/8lUxUjFW/lx/lUbkXYXLpDM+R46da26wNh4gtX3utMrIb4oGKZitzAlR0WLLVwMNX/Z25J2 s+b2wjq3LtyzFiOJT5k8cop7T7crKev+jOYH/WuaTgps0Ke4U2jZFr992ZQbPADlmOZubHr+aeW HSwXDmT6/dqjM2j3lyT9b3CY9fsqASsPZfBdz1JvknZq4QQ/q1dKcXWI9k+dZcc84l4kta/W0ww YJJZumqkrVg== X-Google-Smtp-Source: AGHT+IFOOPVLVl4KULolIHWOYZmwzfjYMlb3N/Tl8UewTpweLLV3DVvwqYV3634nXbJ5TeGjaydwFQ== X-Received: by 2002:a05:600c:3111:b0:456:1904:27f3 with SMTP id 5b1f17b1804b1-45892bc55d8mr38864365e9.18.1753892603663; Wed, 30 Jul 2025 09:23:23 -0700 (PDT) Received: from rltb ([2a01:e0a:3f3:fb51:d168:7163:fc6b:404b]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4589952a60fsm30928235e9.23.2025.07.30.09.23.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Jul 2025 09:23:23 -0700 (PDT) From: Robert Pluim To: Eli Zaretskii Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate In-Reply-To: <86seidvf76.fsf@gnu.org> References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> Date: Wed, 30 Jul 2025 18:23:22 +0200 Message-ID: <87fredabr9.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: eggert@cs.ucla.edu, 79124@debbugs.gnu.org, rms@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: -1.0 (-) >>>>> On Wed, 30 Jul 2025 19:03:25 +0300, Eli Zaretskii said: >> From: Robert Pluim >> Cc: eggert@cs.ucla.edu, rms@gnu.org, 79124@debbugs.gnu.org >> Date: Wed, 30 Jul 2025 17:33:26 +0200 >>=20 >> >>>>> On Wed, 30 Jul 2025 18:29:40 +0300, Eli Zaretskii said: >>=20 >> >> From: Robert Pluim >> >> Cc: Paul Eggert , Richard Stallman , >> >> 79124@debbugs.gnu.org >> >> Date: Wed, 30 Jul 2025 16:11:15 +0200 >> >>=20 >> >> We sometimes also read from .emacs.d/network-security.data under = -Q, >>=20 Eli> Not at startup time, right? You are talking about calling some Eli> network-related APIs. >>=20 >> Right. But it=CA=BCs still surprising that Emacs reads from ~/.emacs= .d when >> -Q is specified. >>=20 >> Basically it happens whenever `nsm-verify-connection' calls >> `nsm-host-settings'. We could add a check for "-Q" there. Eli> OTOH, it's quite annoying to type the same responses to the NSM Eli> prompts when trying stuff in "emacs -Q". Yes, but if you save the result, then the 2nd time you run the test you don=CA=BCt get prompted, and you wonder what you broke :-) Eli> There is "emacs -D", which perhaps could be more "pristine". Patc= hes Eli> welcome. Eli> That said, these options are of interest only to Emacs hackers. Yes. The HOME trick is enough for me. Robert --=20 From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 13:02:44 2025 Received: (at 79124) by debbugs.gnu.org; 30 Jul 2025 17:02:45 +0000 Received: from localhost ([127.0.0.1]:42397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhACS-0006Yn-KH for submit@debbugs.gnu.org; Wed, 30 Jul 2025 13:02:44 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:54192) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhACQ-0006YL-BJ for 79124@debbugs.gnu.org; Wed, 30 Jul 2025 13:02:42 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 297663C010841; Wed, 30 Jul 2025 10:02:36 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id 1kgKooAll2Il; Wed, 30 Jul 2025 10:02:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id F3CE13C01084A; Wed, 30 Jul 2025 10:02:35 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu F3CE13C01084A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1753894956; bh=2CmU+2h4UvNUUjeCXaLFYW861eauOWuQJBOyduLmmgU=; h=Message-ID:Date:MIME-Version:To:From; b=IVpWBevj5g+kTe+yUX1/Ac5ieFeFIqfGOwpFcG9ZVk48xFoPcH2caK+v6OFOJsAx2 rPsKNVxQ4bmAU3l7hT1qfCSQNY4EDHy77kWkXHaQ+7I1dE5G/Q5Z0+/CmXWBXi4Zoh UcPPQN8VGgE6wS/3bRtwOkQyy8JPMQKsaD8DtU6C5fL7qgTiZIulkyVJzzt0+mGt+4 czz4pq+2IFsiBIVDRCJ4OkgcY/N91UihRmw9epFEE8efc1yHPxyKZZ+lheZYzm2VSt 0Vs62pxBHtG/2vUqv84/HBmD88DyjpAjyvnUxsJuTGkGA4RrC5y5O0XDbrD9VebYxy QrKhDW39enaEA== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id cQ_pdeRhyFQP; Wed, 30 Jul 2025 10:02:35 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id C17CD3C010841; Wed, 30 Jul 2025 10:02:35 -0700 (PDT) Message-ID: <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> Date: Wed, 30 Jul 2025 10:02:35 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii , Robert Pluim References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86seidvf76.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-07-30 09:03, Eli Zaretskii wrote: > OTOH, it's quite annoying to type the same responses to the NSM > prompts when trying stuff in "emacs -Q". > > There is "emacs -D", which perhaps could be more "pristine". Patches > welcome. Thanks for looking into it. As someone who merely wants to run Emacs in a clean state I find all these options confusing. For example I didn't know about -D, and I had forgotten about the $HOME trick. It would be convenient to have an easy way to do all this stuff. How about a new option, say -R or --really-quick, that causes Emacs to omit all this setup information so as to get a clean slate? It would cause Emacs to not access anything under $HOME during setup, as well as by doing everything that -Q and -D do, along with any similar options (--no-desktop, --no-build-details, anything else?). From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 00:26:15 2025 Received: (at 79124) by debbugs.gnu.org; 31 Jul 2025 04:26:15 +0000 Received: from localhost ([127.0.0.1]:44968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhKru-0001nX-Ia for submit@debbugs.gnu.org; Thu, 31 Jul 2025 00:26:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55736) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhKrq-0001n4-V4 for 79124@debbugs.gnu.org; Thu, 31 Jul 2025 00:26:11 -0400 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 1uhKrk-0000nI-Cd; Thu, 31 Jul 2025 00:26:04 -0400 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=mid89MaiMpmQfu2Eq+QkU34/RDknzGnvcuMLm8jMFa8=; b=TtSkjDp5/Ynp wyVSk8lw7ABVYtirdTMkxZpP3Su4tqExiiBKPGwf2PEj3Nl1Fr4IcP+a+xqFldphRNO+oRWRLcooh BH+zsBGn5rPqmWfZW+RvhltyOhv5nlEkuaR5vhMvL/nbE/MSiPrTtZuvHi/CnKCd16XLKBwVVHu09 H6/Z4TsmZFZpuavAO5NvGJ2e7kARn/+RJcVlXqix0lSY6mj1Xas0c3/P+fc6Scak3CumF05l7rSDn 3lnlA6AzQo5QQvMcEJl/JU4uTlWGYiTuQcIG1U4pi9enfGYG/EajPemSp8pKlw9FM+++26ffqmPoP a6mE007UDUm8OO4xDB2Q7g==; Date: Thu, 31 Jul 2025 07:25:43 +0300 Message-Id: <86o6t1ugu0.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> (message from Paul Eggert on Wed, 30 Jul 2025 10:02:35 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Wed, 30 Jul 2025 10:02:35 -0700 > Cc: rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-07-30 09:03, Eli Zaretskii wrote: > > OTOH, it's quite annoying to type the same responses to the NSM > > prompts when trying stuff in "emacs -Q". > > > > There is "emacs -D", which perhaps could be more "pristine". Patches > > welcome. > > Thanks for looking into it. As someone who merely wants to run Emacs in > a clean state I find all these options confusing. For example I didn't > know about -D, and I had forgotten about the $HOME trick. It would be > convenient to have an easy way to do all this stuff. One only knows about that if one needs it. This stuff is only useful for Emacs hackers. > How about a new option, say -R or --really-quick, that causes Emacs to > omit all this setup information so as to get a clean slate? I'd prefer not to add another startup option. Here, you didn't even know about -D, so what are the chances someone else will know about this new option? Would it be possible to make -D omit those few accesses that it doesn't now? > It would > cause Emacs to not access anything under $HOME during setup, as well as > by doing everything that -Q and -D do, along with any similar options > (--no-desktop, --no-build-details, anything else?). Well, "access nothing under $HOME" won't work with natively-compiled Emacs, because it needs to access files in ~/.emacs.c/eln-cache/. The "-nw" session always does that, and even without -nw Emacs sometimes does need to access that directory. But otherwise, yes, we could avoid loading abbrevs and auto-save-list files (which AFAIU are the only other files read at startup under -Q). Not sure what you want to do about .terminfo. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 01:05:41 2025 Received: (at 79124) by debbugs.gnu.org; 31 Jul 2025 05:05:41 +0000 Received: from localhost ([127.0.0.1]:45204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhLU5-0004dT-5X for submit@debbugs.gnu.org; Thu, 31 Jul 2025 01:05:41 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:36824) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhLU2-0004cm-73 for 79124@debbugs.gnu.org; Thu, 31 Jul 2025 01:05:38 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id E6CFA3C010841; Wed, 30 Jul 2025 22:05:31 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id 1-D3LZ5XlM1k; Wed, 30 Jul 2025 22:05:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id BE8943C01084E; Wed, 30 Jul 2025 22:05:31 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu BE8943C01084E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1753938331; bh=sndYTFZCskazCasDvMoQoiUaYU0p6JYhjxy/T1JuBgw=; h=Message-ID:Date:MIME-Version:To:From; b=itBvZHInXm7gvLdVxYWU+B1bgkn8JriGxEaJ5rWHi8imZhbXyG6V4qrbp/EELVeFL c5Ylqkmroafr8gonaWO8eKamKFEv0kE39/TIWHyaTPJ60ImXN5kYAtiDtj3F0v0wpy xrdeEkK1jC2560bRVuC4fSyg2C0WQreabO50rVi04FsyBFrVXwnvFs//DRJzmAylkg 2+VyHRgWZnNTF5Aa8h5RyH52L2nUDH1g4ACsKiRBjC5lWoYZjGxRYiKYdKyahlngPK NfOcJ7kk/WqaVLZoPxrwgHSyPSAmBKDh0jQhoM3YyuFHL0D6QE6x5wDK1q95gyaUJM 5idtU8sfCKiJw== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id v9YNurG2yW2O; Wed, 30 Jul 2025 22:05:31 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 9745B3C010841; Wed, 30 Jul 2025 22:05:31 -0700 (PDT) Message-ID: <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> Date: Wed, 30 Jul 2025 22:05:31 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86o6t1ugu0.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-07-30 21:25, Eli Zaretskii wrote: > I'd prefer not to add another startup option. Here, you didn't even > know about -D, so what are the chances someone else will know about > this new option? The point is that one needs to use multiple options now, along with setting at least one environment variable at least part of the time, and it's easy to forget this stuff. How about -QQ? That'd be easy to remember. The idea is to get a simple setup that yields reproducible results regardless of user. > Would it be possible to make -D omit those few accesses that it > doesn't now? I assume it would be. I don't know how -D works, though. > Well, "access nothing under $HOME" won't work with natively-compiled > Emacs, because it needs to access files in ~/.emacs.c/eln-cache/. ? I just now ran natively-compiled Emacs with HOME set to a nonexistent directory, and it worked fine. I was using 'emacs -D -Q -nw' on Fedora 42 x86-64. > Not sure what you want to > do about .terminfo. I don't want to load it either, because it makes tests irreproducible. I'm sure this could be arranged somehow. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 01:46:21 2025 Received: (at 79124) by debbugs.gnu.org; 31 Jul 2025 05:46:21 +0000 Received: from localhost ([127.0.0.1]:45481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhM7R-0007vQ-Bl for submit@debbugs.gnu.org; Thu, 31 Jul 2025 01:46:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43686) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhM7P-0007v2-E0 for 79124@debbugs.gnu.org; Thu, 31 Jul 2025 01:46:20 -0400 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 1uhM7J-0001jY-2c; Thu, 31 Jul 2025 01:46:13 -0400 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=SXo8XjMFMp9rimr9T+uU6xFDJ08Aah6KCxTYVwUsBKg=; b=od83KMKQSd+V 3ve9pxpoS9bVWBwLT4bpR5NybZJKfuqTQI5UlWt0mp7CbH6u1ptx6gP44iXKKxxXivucGy7Rbm61x g1v5VGBnsZuQqjFmqgVH9uYGcy1Cg9Di3W+vX4vcr7mBszZmLNlmOF4Hl0OqieJvdD38n2ScQQkE4 wmeqKxDTSGpK/RRIA3sEqCUpLxHwbLhgnahV4r2WN+jka72S/mTcZLktIhDZTYmGe3XIBMEw1y0cd Tb13DusVht+Zxn1fXnTYhz9EdCUOnmxXwOEKFbZYpyogMeyTZpunq7Zi7CoiXlwxFASqjjWZBh/zd o2PiXvWvpXRTMN/1/24xkg==; Date: Thu, 31 Jul 2025 08:45:54 +0300 Message-Id: <86bjp0vrot.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> (message from Paul Eggert on Wed, 30 Jul 2025 22:05:31 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Wed, 30 Jul 2025 22:05:31 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-07-30 21:25, Eli Zaretskii wrote: > > > I'd prefer not to add another startup option. Here, you didn't even > > know about -D, so what are the chances someone else will know about > > this new option? > > The point is that one needs to use multiple options now, along with > setting at least one environment variable at least part of the time, and > it's easy to forget this stuff. > > How about -QQ? That'd be easy to remember. The idea is to get a simple > setup that yields reproducible results regardless of user. It's slightly better, but I'm not sure it's better than "-Q -D". > > Would it be possible to make -D omit those few accesses that it > > doesn't now? > > I assume it would be. I don't know how -D works, though. It sets emacs-basic-display non-nil in startup.el. > > Well, "access nothing under $HOME" won't work with natively-compiled > > Emacs, because it needs to access files in ~/.emacs.c/eln-cache/. > > ? I just now ran natively-compiled Emacs with HOME set to a nonexistent > directory, and it worked fine. I was using 'emacs -D -Q -nw' on Fedora > 42 x86-64. "Worked fine" in what sense? Are you saying it didn't need to natively-compile anything? Are you sure? When Emacs starts with -nw, it needs to load a library from lisp/term/ that corresponds to the terminal (if there is such a library). If it cannot find a .eln file for that, it will attempt to compile it natively, and that loads a bunch of Lisp packages needed for the compilation. In a normally-configured system, all those files are in ~/.emacs.c/eln-cache/. > > Not sure what you want to > > do about .terminfo. > > I don't want to load it either, because it makes tests irreproducible. > I'm sure this could be arranged somehow. Fine, but this is out of scope of Emacs, no? When and why is this accessed? Maybe some special terminal type could avoid that? From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 10:43:29 2025 Received: (at 79124) by debbugs.gnu.org; 31 Jul 2025 14:43:29 +0000 Received: from localhost ([127.0.0.1]:48789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhUVE-0005iu-M6 for submit@debbugs.gnu.org; Thu, 31 Jul 2025 10:43:29 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:54650) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhUVB-0005ia-F8 for 79124@debbugs.gnu.org; Thu, 31 Jul 2025 10:43:26 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id A0E2B3C010841; Thu, 31 Jul 2025 07:43:19 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id nhViTbWPSChf; Thu, 31 Jul 2025 07:43:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 77DA63C01085D; Thu, 31 Jul 2025 07:43:19 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 77DA63C01085D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1753972999; bh=ElZRnHIy3uW6xWxjhatiko3fRZQBwkysXM8ZYICTsDY=; h=Message-ID:Date:MIME-Version:To:From; b=ZyS+DDyHlrfHsRQVjJIh/ujwYuk/8siCFPVG4THgVdLbKKAeb8VJtTSG115z3jYdz jdgTQZNkYIvWvQBlV0tyQMRBbsDRj3knCelQW++jbXo9C49CMjRZjVkrqmk1JxaMNq DzTYQFvoJ9OgwKVkztD1Yz2zCscJRfz0o3w0h8obVATmf+K2huRo+HGmTC2cZ4M1/R aTIbEY+8RNFA4ZHSps3xNYbvFtA9zPS7NYi3VnDRnNaqdiWXPv2YCUn0dghjzt7UqO UuOKmFV7lALPE/9EpgVHJQ8lGlj7XUDhAxPHxVxKLCdRbqvRnb9ocS4YBb14nHWJDE QILWJMZJvYj/w== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 5-8ujTniHN-O; Thu, 31 Jul 2025 07:43:19 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 52EC33C010841; Thu, 31 Jul 2025 07:43:19 -0700 (PDT) Message-ID: Date: Thu, 31 Jul 2025 07:43:09 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86bjp0vrot.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-07-30 22:45, Eli Zaretskii wrote: > It's slightly better, but I'm not sure it's better than "-Q -D". I could live with -Q -D if it was a clean slate, though it's not now. If=20 there are good reasons for it to not be a clean slate, I'd like a simple=20 way to get one. >> I don't know how -D works, though. >=20 > It sets emacs-basic-display non-nil in startup.el. Apparently that's not enough to get rid of all display-related data=20 slurping from $HOME. Is it the intent of -D to stop such slurping? >=20 >>> Well, "access nothing under $HOME" won't work with natively-compiled >>> Emacs, because it needs to access files in ~/.emacs.c/eln-cache/. >> >> ? I just now ran natively-compiled Emacs with HOME set to a nonexisten= t >> directory, and it worked fine. I was using 'emacs -D -Q -nw' on Fedora >> 42 x86-64. >=20 > "Worked fine" in what sense? Are you saying it didn't need to > natively-compile anything? Are you sure? Oh, I assume it tried to natively compile. And it put up a *Warning*=20 buffer with blue-colored BLACK SQUARE (U+25A0) saying " =E2=96=A0 Warnin= g=20 (initialization): Unable to create `user-emacs-directory' (~/.emacs.d/).=20 Any data that would normally be written there may be lost! If you never=20 want to see this message again, customize the variable=20 `user-emacs-directory-warning'." But I didn't see any problems after that= . Presumably a new -QQ option would disable that part of the startup. >>> Not sure what you want to >>> do about .terminfo. >> >> I don't want to load it either, because it makes tests irreproducible. >> I'm sure this could be arranged somehow. >=20 > Fine, but this is out of scope of Emacs, no? When and why is this > accessed? Maybe some special terminal type could avoid that? Yes, something like that, either as part of -QQ or of "-Q -D" (though I=20 don't know whether it'd belong to -Q or to -D). From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 11:53:27 2025 Received: (at 79124) by debbugs.gnu.org; 31 Jul 2025 15:53:28 +0000 Received: from localhost ([127.0.0.1]:49258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhVax-0001tF-6L for submit@debbugs.gnu.org; Thu, 31 Jul 2025 11:53:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33724) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhVav-0001sp-3g for 79124@debbugs.gnu.org; Thu, 31 Jul 2025 11:53:25 -0400 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 1uhVao-0000aw-S1; Thu, 31 Jul 2025 11:53:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=o0kQcck5pI0H1GcNEBDlTOTASTmuQ7TJVCww6vNhPvU=; b=nZbdL/JYN++hvA0d1AEz jnjaCezvNXsoleOjT7v/JoeWoO+NRgSGTF47fCwIdGVoLd97Z3ywMoxrUsNQ9PH4bbh/8cjacbZTB CDoTKcW1RQLXJjIsxFEYWmwjriwSdwIWFZJoXFW03Rk53rooF9jzFx+GVZoHWj1Tm6JZIviD4/qFi SjsXOcPzLRGU4IA3FFGOoLwvgL22S5yDvrBfVR+XAa+cD8Mng9YDU/WfZiH2WufelIJzwjxHUEK3r 0heKQZUExNIJcimG05CMsKknS7BulI43CuhQKRd27PrwNOkuowib/EkJ29phKtzOXVNtxFr01Ejxj sDg3bketEAUZdQ==; Date: Thu, 31 Jul 2025 18:53:09 +0300 Message-Id: <864iusuzkq.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Thu, 31 Jul 2025 07:43:09 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Thu, 31 Jul 2025 07:43:09 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-07-30 22:45, Eli Zaretskii wrote: > > > It's slightly better, but I'm not sure it's better than "-Q -D". > > I could live with -Q -D if it was a clean slate, though it's not now. If > there are good reasons for it to not be a clean slate, I'd like a simple > way to get one. > > >> I don't know how -D works, though. > > > > It sets emacs-basic-display non-nil in startup.el. > > Apparently that's not enough to get rid of all display-related data > slurping from $HOME. Is it the intent of -D to stop such slurping? Of course, it's not enough: we need to change the code. I was just telling you how -D takes its effect, because I thought that was what you were asking about. > >>> Well, "access nothing under $HOME" won't work with natively-compiled > >>> Emacs, because it needs to access files in ~/.emacs.c/eln-cache/. > >> > >> ? I just now ran natively-compiled Emacs with HOME set to a nonexistent > >> directory, and it worked fine. I was using 'emacs -D -Q -nw' on Fedora > >> 42 x86-64. > > > > "Worked fine" in what sense? Are you saying it didn't need to > > natively-compile anything? Are you sure? > > Oh, I assume it tried to natively compile. And it put up a *Warning* > buffer with blue-colored BLACK SQUARE (U+25A0) saying " ■ Warning > (initialization): Unable to create `user-emacs-directory' (~/.emacs.d/). > Any data that would normally be written there may be lost! If you never > want to see this message again, customize the variable > `user-emacs-directory-warning'." But I didn't see any problems after that. So this is not really "working fine". Emacs with native compilation does need to access files under the user's home directory, at least in the -nw case and if it needs to load some Lisp. > Presumably a new -QQ option would disable that part of the startup. You want to disable JIT native-compilation as well? Why? > >>> Not sure what you want to > >>> do about .terminfo. > >> > >> I don't want to load it either, because it makes tests irreproducible. > >> I'm sure this could be arranged somehow. > > > > Fine, but this is out of scope of Emacs, no? When and why is this > > accessed? Maybe some special terminal type could avoid that? > > Yes, something like that, either as part of -QQ or of "-Q -D" (though I > don't know whether it'd belong to -Q or to -D). If you want to have a working Emacs that can edit stuff, then disregarding Terminfo might be a problem. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 12:19:31 2025 Received: (at 79124) by debbugs.gnu.org; 31 Jul 2025 16:19:31 +0000 Received: from localhost ([127.0.0.1]:49382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhW0B-0003V1-0E for submit@debbugs.gnu.org; Thu, 31 Jul 2025 12:19:31 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:52032) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhW08-0003Uc-Lg for 79124@debbugs.gnu.org; Thu, 31 Jul 2025 12:19:29 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 4F8423C010841; Thu, 31 Jul 2025 09:19:22 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id f3rGKyaMyTfE; Thu, 31 Jul 2025 09:19:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 25F9E3C01085F; Thu, 31 Jul 2025 09:19:22 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 25F9E3C01085F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1753978762; bh=hIVfiXxkLIgO1pDZZyJovjc1l0jg7eg/laR6rkBEStQ=; h=Message-ID:Date:MIME-Version:To:From; b=F85QRCT4DQkx6VnDRx4U4BppiLfkLK1r+LW9nlDwc3I/sm2Q/uDNIIT1cq5iPaKi5 omr7aODUY1suUzJp1WAF3/NTQ72Q4qIm1QZGcseD58kUpoduIx1pp7xDqugixlgeul c+te0TTk1v7u9ZlKA9aHIJc5wMiW7xaIdim7FxvhZBgJ3hhEGkf406H9ERY3py9VWs MwAmReVFnkmfyZWeaGrK+qYvbrBdfD0wL0zli1igc4RjITlSl8wOdbK0SUa2xbPhz1 k2UcJy9HOLEJJHFhMl0aJa1BmiYhfRX0SWC8YR2g8HPOyWvV/SFAQjVmKhH5D5eY6/ fg2d0jjdo69zA== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id rMkP3JQW4cI0; Thu, 31 Jul 2025 09:19:22 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 026C03C010841; Thu, 31 Jul 2025 09:19:21 -0700 (PDT) Message-ID: Date: Thu, 31 Jul 2025 09:19:20 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <864iusuzkq.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-07-31 08:53, Eli Zaretskii wrote: > So this is not really "working fine". Emacs with native compilation > does need to access files under the user's home directory, at least in > the -nw case and if it needs to load some Lisp. I don't see why. If native-compiled modules aren't available Emacs can get by with byte-compiled or even source files. And if that doesn't suffice (why not?) Emacs can create a /tmp cache directory and use that. At any rate, I'm still puzzled by the idea that Emacs doesn't work now in this situation. What's not working (other than the diagnostic, which we can easily suppress)? For example, if I run this shell command on Fedora: HOME=/nosuch emacs -nw -D -Q I see that Emacs attempts to access /nosuch/.emacs.d/eln-cache and a bunch of other files under /nosuch, the accesses all fail, and Emacs keeps chugging along. What am I missing? (And why does it matter whether I use -nw?) >> Presumably a new -QQ option would disable that part of the startup. > > You want to disable JIT native-compilation as well? Why? I don't necessarily want to disable it. I merely want Emacs to not rely on any cache in my home directory. Emacs can do whatever jitting it likes, so long as jits from a clean slate. > If you want to have a working Emacs that can edit stuff, then > disregarding Terminfo might be a problem. For this use case that's a feature not a problem. When testing, I don't want Emacs to consult the user's private ~/.terminfo file even if one exists, because I want the run to be reproducible independent of user. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 01 01:54:58 2025 Received: (at 79124) by debbugs.gnu.org; 1 Aug 2025 05:54:58 +0000 Received: from localhost ([127.0.0.1]:53879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhijJ-0005SG-B9 for submit@debbugs.gnu.org; Fri, 01 Aug 2025 01:54:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45818) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhijH-0005Rf-M9 for 79124@debbugs.gnu.org; Fri, 01 Aug 2025 01:54:56 -0400 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 1uhijB-0002ZY-QN; Fri, 01 Aug 2025 01:54:49 -0400 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=T4o7oKbBt0jDEARXHCoh7LU3Nryj0O23yMmd4DDXoEg=; b=cEeIWjR+thtb EzV5YoXDN5//tSVs5lBc9sNS6BQ0tCmn3yLtj8xhBkHEfGYQRv/ytDYudcuQ8fXhoEn/Y4dnGMPAA /ib8ggQ3IcOVc1xfE8chNbVv25GQdE7Ux3A1j3Anvqc3a611wIl/4Q5/rtpqNLmCB4aXD8x57MlwW 9e3/zqGfiPmvAbRu2w1+glJSSyVfxiPEt60DZKEOq+Usx5n4KrkAAppXMOyW2LuXGUfjgChyUCknI zP9LAmT6odAd8Yc0Jxc8D9ay3iiSw/2pcYnCgh7U4Ebqw7/ah9NFG76SRS/Ah5xXRD3nIa9NZ7rOX eRQBZsn+H/w1lmqsLYIYAw==; Date: Fri, 01 Aug 2025 08:54:31 +0300 Message-Id: <861ppvvb6w.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Thu, 31 Jul 2025 09:19:20 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Thu, 31 Jul 2025 09:19:20 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-07-31 08:53, Eli Zaretskii wrote: > > > So this is not really "working fine". Emacs with native compilation > > does need to access files under the user's home directory, at least in > > the -nw case and if it needs to load some Lisp. > > I don't see why. If native-compiled modules aren't available Emacs can > get by with byte-compiled or even source files. And if that doesn't > suffice (why not?) Emacs can create a /tmp cache directory and use that. Because that's not how the relevant code is written, and I don't see why we would need to make such significant changes in that tricky part of Emacs just to support a requirement to not access any files in the user's home directory. This kind of operation is a very niche feature, useful for very few Emacs users, so making deep changes in code that took us 3 major releases to get right is not something I'm glad to do. I don't object to small changes in support of what you want, but that's it. There's no way Emacs built with native-compilation can start without looking up *.eln files and/or writing *.eln files, unless you ensure with 110% probability that it doesn't need to load any Lisp that is not preloaded. Ensuring that is not easy (and not possible at all in the -nw case), but that's the only way it's going to work. > At any rate, I'm still puzzled by the idea that Emacs doesn't work now > in this situation. What's not working (other than the diagnostic, which > we can easily suppress)? For example, if I run this shell command on Fedora: > > HOME=/nosuch emacs -nw -D -Q > > I see that Emacs attempts to access /nosuch/.emacs.d/eln-cache and a > bunch of other files under /nosuch, the accesses all fail, and Emacs > keeps chugging along. What am I missing? (And why does it matter whether > I use -nw?) I explained why -nw matters: Emacs needs to load lisp/term/xterm.el (or some other terminal-specific library). Since those libraries are not preloaded, Emacs looks up their *.eln files, and if it doesn't find them, it will load xterm.elc and attempt to natively-compile xterm.el into xterm.eln, putting xterm.eln in ~/.emacs.d/eln-cache's subdirectory (and then load it). That's what JIT compilation is about. > >> Presumably a new -QQ option would disable that part of the startup. > > > > You want to disable JIT native-compilation as well? Why? > > I don't necessarily want to disable it. I merely want Emacs to not rely > on any cache in my home directory. Emacs can do whatever jitting it > likes, so long as jits from a clean slate. You can only achieve that if you modify native-comp-eln-load-path to replace the first element by some temporary writable directory. This should be done very early, I hope that early-init file is early enough (but I haven't tried that). Otherwise, this is currently impossible, and I'm not very interested in changing how JIT compilation works to support your use case by default, because your use case is marginal and not very important, and because that stuff runs at startup and is quite delicate. > > If you want to have a working Emacs that can edit stuff, then > > disregarding Terminfo might be a problem. > > For this use case that's a feature not a problem. When testing, I don't > want Emacs to consult the user's private ~/.terminfo file even if one > exists, because I want the run to be reproducible independent of user. I don't know what could be in ~/.terminfo, so I don't understand the implications of that. If it could affect how the terminal performs its functions, like moving the cursor or inserting/deleting text in the screen, it could be important for the Emacs operation. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 02 14:53:28 2025 Received: (at 79124) by debbugs.gnu.org; 2 Aug 2025 18:53:29 +0000 Received: from localhost ([127.0.0.1]:37765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiHMG-00036z-IY for submit@debbugs.gnu.org; Sat, 02 Aug 2025 14:53:28 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:37468) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uiHME-00036e-6g for 79124@debbugs.gnu.org; Sat, 02 Aug 2025 14:53:26 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id F16273C01086C; Sat, 2 Aug 2025 11:53:19 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id VYLVNQ8KtA6X; Sat, 2 Aug 2025 11:53:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id C662C3C0149D7; Sat, 2 Aug 2025 11:53:19 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu C662C3C0149D7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754160799; bh=rkpfyAmRz3X6nnZte1gnvi9JngPOk4awQ25Oj3+pox8=; h=Message-ID:Date:MIME-Version:To:From; b=LF5HhbP5PpNBb0ScBHc/P2BlwY2BUSeUtBwnjK2uYvapt36BLIlfAaRx62s7bGg9C otczaBLsvAE5PDwxTfz+bHXZfITeIcsbNbRuBCIFrx+Hkgh4z3o09lln3P0lZUtLCJ 3iFZ96GtAz0zJvI0HOVGXEgrk2o76ZF8g53qzA4/1DWwQEtHsMtU5/KKuYSSti3dLV m5f04a5rNiDEvYgscCua0UTZXYTeMNEj2yU+U1z8wdML1k59MuuCNMC39wRXGKk12f uwZ3a0a2ZfVHoa4Ne8Jq9ilBNwrfeTV7JCqta32oxF6d755O+CEIqycuapZLD0fBSg PpXRqWsrQxE7w== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id AMhMfDP30BVO; Sat, 2 Aug 2025 11:53:19 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id A22F73C01086C; Sat, 2 Aug 2025 11:53:19 -0700 (PDT) Message-ID: <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> Date: Sat, 2 Aug 2025 11:53:19 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <861ppvvb6w.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-07-31 22:54, Eli Zaretskii wrote: > I explained why -nw matters: Emacs needs to load lisp/term/xterm.el > (or some other terminal-specific library). Since those libraries are > not preloaded, Emacs looks up their *.eln files, and if it doesn't > find them, it will load xterm.elc and attempt to natively-compile > xterm.el into xterm.eln, putting xterm.eln in ~/.emacs.d/eln-cache's > subdirectory (and then load it). That's what JIT compilation is > about. That's all fine, but the main point is that, -nw or not, everything works for me despite there being no eln cache. Nothing goes wrong. Emacs works fine other than spurious diagnostics that a new flag would suppress. So I'm still puzzled as to why the eln cache is essential for Emacs to operate. Even if something (but what?) goes wrong for interactive use, my main use case is -batch (for testing) where terminal-specific libraries largely don't matter. > if you modify native-comp-eln-load-path to > replace the first element by some temporary writable directory. This > should be done very early That's doable and fairly simple, though I'm still puzzled as to why it's needed. Alternatively, Emacs could be taught to not trust any existing files in the eln cache. That should be a simple change. Emacs probably has a "don't trust" mode already for files generated by older versions, and the mode just needs to be enabled for reproducible testing. > I don't know what could be in ~/.terminfo, so I don't understand the > implications of that. I know what could be in ~/.terminfo, and it's definitely not important for reproducible testing. It's worse than not important: it's counterproductive. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 02 15:29:11 2025 Received: (at 79124) by debbugs.gnu.org; 2 Aug 2025 19:29:11 +0000 Received: from localhost ([127.0.0.1]:37870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiHuo-00058H-Ra for submit@debbugs.gnu.org; Sat, 02 Aug 2025 15:29:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36774) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uiHum-000582-He for 79124@debbugs.gnu.org; Sat, 02 Aug 2025 15:29:09 -0400 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 1uiHug-0004b0-CX; Sat, 02 Aug 2025 15:29:02 -0400 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=TMtjLA5WfHSNVCUCo63SJXdubS6c13ZgaFe8OVsR1tM=; b=eFtzFm+ZDp4o 25/L7lK4DfozwPoHuht/c/nK4LpkyNM4NmMocNSnLlgHvZ6Lrn96Ou8YNzghSXQmaoesD0TyYLi7K qb4Gp7FzPPaZ3ztc8MDSQghy+BPNNZ4kvTZs2vX22UDHQFgoXwtypHTu9wEOasrrgEIU9k9Ap4xS9 2wluFeUuNyjDdsxSq22+CSWGo4GtI1LTpVg5A7d8p1SavE/DMEUUZLVpjHwYEOI0gAuL26+ra4l+R rmPr9W4+N02HKvRrySylQ/5bTGtDWb1t463z34809uJAkU+9/o5Fom32fo1lGxgBot1s47Ktqo0GF SlWsgT22Ew6BqIZ3d0CQXg==; Date: Sat, 02 Aug 2025 22:28:51 +0300 Message-Id: <86zfchplos.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> (message from Paul Eggert on Sat, 2 Aug 2025 11:53:19 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Sat, 2 Aug 2025 11:53:19 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-07-31 22:54, Eli Zaretskii wrote: > > I explained why -nw matters: Emacs needs to load lisp/term/xterm.el > > (or some other terminal-specific library). Since those libraries are > > not preloaded, Emacs looks up their *.eln files, and if it doesn't > > find them, it will load xterm.elc and attempt to natively-compile > > xterm.el into xterm.eln, putting xterm.eln in ~/.emacs.d/eln-cache's > > subdirectory (and then load it). That's what JIT compilation is > > about. > > That's all fine, but the main point is that, -nw or not, everything > works for me despite there being no eln cache. Nothing goes wrong. Emacs > works fine other than spurious diagnostics that a new flag would > suppress. So I'm still puzzled as to why the eln cache is essential for > Emacs to operate. Because Emacs writes there the *.eln files it produces at startup. > > if you modify native-comp-eln-load-path to > > replace the first element by some temporary writable directory. This > > should be done very early > > That's doable and fairly simple, though I'm still puzzled as to why it's > needed. Because the default value of that variable has ~/.emacs.d/eln-cache as its first element, whereas you want to avoid accessing the user's home directory. > Alternatively, Emacs could be taught to not trust any existing files in > the eln cache. That should be a simple change. Emacs probably has a > "don't trust" mode already for files generated by older versions, and > the mode just needs to be enabled for reproducible testing. I don't understand what you are saying here. The trust thing is for security, so why would it be applicable to *.eln files? > > I don't know what could be in ~/.terminfo, so I don't understand the > > implications of that. > > I know what could be in ~/.terminfo, and it's definitely not important > for reproducible testing. It's worse than not important: it's > counterproductive. Then maybe you also know how to force the curses libraries not to look there? Again, this is not an Emacs problem. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 11:52:46 2025 Received: (at 79124) by debbugs.gnu.org; 3 Aug 2025 15:52:47 +0000 Received: from localhost ([127.0.0.1]:45285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uib0w-00006o-HR for submit@debbugs.gnu.org; Sun, 03 Aug 2025 11:52:46 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:48612) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uib0s-00006T-Sd for 79124@debbugs.gnu.org; Sun, 03 Aug 2025 11:52:44 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id C0AEC3C0149CB; Sun, 3 Aug 2025 08:52:36 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id yTqvhrM9D151; Sun, 3 Aug 2025 08:52:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 94F623C0149D0; Sun, 3 Aug 2025 08:52:36 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 94F623C0149D0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754236356; bh=gOw282GFXmRTyv+GA7mpU4VpbUgHyBxqdGP/h7Wn2is=; h=Message-ID:Date:MIME-Version:To:From; b=Vjdrvca8JMLxs8xoyoF8UKty+UobqHBircwf+jALiiP74VI8wP4NvcQef8tmHTCoM 8hRu3VqyXzAQQcXslILiFpRxODEkBlyGyWCC6kzL9TgGqwLOxpOrktJKUMEU9dJBS8 2CYCsv/4emGwyjEJEduS+DhIJxR0XvzexV5hWpTYNMkXgIbBn89PT/RhPcnaWCa3aj nn1d0nwGpmDm1BuiPYgY841Kc2lYFZ3tuBGzOejPalXnfn2s34ZfelSF4kL40rwVt8 n3seXmxWN0yADNNDNnu+usbFu4ricqMWXL0W6Bc7cnTheQSyfi4vg3zTgjbqtuRreu BZCw2c0d3DoAA== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id i0rJA8rWHehF; Sun, 3 Aug 2025 08:52:36 -0700 (PDT) Received: from penguin.cs.ucla.edu (unknown [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 68FA53C0149CB; Sun, 3 Aug 2025 08:52:36 -0700 (PDT) Message-ID: <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> Date: Sun, 3 Aug 2025 08:52:36 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86zfchplos.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-08-02 12:28, Eli Zaretskii wrote: >> From: Paul Eggert >> -nw or not, everything >> works for me despite there being no eln cache. Nothing goes wrong. Emacs >> works fine other than spurious diagnostics that a new flag would >> suppress. So I'm still puzzled as to why the eln cache is essential for >> Emacs to operate. > > Because Emacs writes there the *.eln files it produces at startup. But Emacs doesn't do that. Under the scenario I gave, Emacs does not write *.eln files as there's no place to write them: the cache directory does not exist and cannot be created. And Emacs still works fine. And this is better for testing, as test results do not rely on the contents of the user's home directory. > I don't understand what you are saying here. The trust thing is for > security, so why would it be applicable to *.eln files? I'm a bit fuzzy on exactly when Emacs refuses to load an *.eln file, but whatever reason Emacs doesn't do it (security, API incompatibility, wrong architecture, out of date with respect to source, ...) we can add the new -QQ option as another reason not to do it. This should not be a drastic change. >>> I don't know what could be in ~/.terminfo, so I don't understand the >>> implications of that. >> >> I know what could be in ~/.terminfo, and it's definitely not important >> for reproducible testing. It's worse than not important: it's >> counterproductive. > > Then maybe you also know how to force the curses libraries not to look > there? Again, this is not an Emacs problem. It's an Emacs problem only in that a bit of Emacs code needs to be added to force the curses libraries not to look there. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 12:10:42 2025 Received: (at 79124) by debbugs.gnu.org; 3 Aug 2025 16:10:42 +0000 Received: from localhost ([127.0.0.1]:45336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uibII-0001CF-2r for submit@debbugs.gnu.org; Sun, 03 Aug 2025 12:10:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57250) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uibIF-0001Br-UT for 79124@debbugs.gnu.org; Sun, 03 Aug 2025 12:10:40 -0400 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 1uibI9-000635-04; Sun, 03 Aug 2025 12:10:33 -0400 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=fsZ49EeIiuEdlUSMaqsCM3IQ1MN7mKZtFX+WbJPo2LY=; b=O7gWeJsXaMQ8 yyw4ZDxzDDTjHfaBYffMvL9zrhuG6gwJewm/MiURqN9z9af2BrBgzUBWbhOMW0pwp0ItQburqakoZ /IEhx1Lj1r2D6rKV2+GC1tMF6tAmoE2MDi8t1KoEKp3Ko36ewSaPq+Tz2z9NSgLlz05nKGyPUcswi Zu8Tfv5tGnXt/CRtQcW2FsMoSorvhEV1xT0Y/dWb79L4+MbHQZWRrjkCNnnlEis4TC22Nbo1jC+rz ViwE3jWcQzoxhX5gGMWA7FPaT8G0VqdhmHr/OlDnCdUrPACwYfGOYy0+jYkrPv8ffqOhbQudCr7BK zNFA7QZ9mGkJmlkvvqyx4w==; Date: Sun, 03 Aug 2025 19:09:38 +0300 Message-Id: <864iuoxu7x.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> (message from Paul Eggert on Sun, 3 Aug 2025 08:52:36 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Sun, 3 Aug 2025 08:52:36 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-08-02 12:28, Eli Zaretskii wrote: > >> From: Paul Eggert > >> -nw or not, everything > >> works for me despite there being no eln cache. Nothing goes wrong. Emacs > >> works fine other than spurious diagnostics that a new flag would > >> suppress. So I'm still puzzled as to why the eln cache is essential for > >> Emacs to operate. > > > > Because Emacs writes there the *.eln files it produces at startup. > > But Emacs doesn't do that. Under the scenario I gave, Emacs does not > write *.eln files as there's no place to write them: the cache directory > does not exist and cannot be created. I don't know what exactly happened in your case, and you never described all of those details. I'm telling you what Emacs is programmed to do. > And Emacs still works fine. For some value of "fine". Since we don't know what happened (which files it tried to compile, if it tried, and where, if anywhere, it wrote the *.eln files), we also don't know exactly what kind of "working Emacs" you got as result. That it succeeded to run some simple commands doesn't necessarily mean it's a healthy session. Maybe it is, maybe it isn't. > And this is better for testing, as test results do not rely on the > contents of the user's home directory. Then your problem is solved, and we can stop this discussion, which from my POV goes nowhere useful? I thought you were asking for some code changes? If you are happy with what we have now, I'm fine with that. Otherwise, I don't think I understand what are you trying to say. > > I don't understand what you are saying here. The trust thing is for > > security, so why would it be applicable to *.eln files? > > I'm a bit fuzzy on exactly when Emacs refuses to load an *.eln file, but > whatever reason Emacs doesn't do it (security, API incompatibility, > wrong architecture, out of date with respect to source, ...) we can add > the new -QQ option as another reason not to do it. This should not be a > drastic change. Sorry, I'm not interested. We already have enough knobs to disable native compilation (they are described in the manual), and I see no reason to add more. > >>> I don't know what could be in ~/.terminfo, so I don't understand the > >>> implications of that. > >> > >> I know what could be in ~/.terminfo, and it's definitely not important > >> for reproducible testing. It's worse than not important: it's > >> counterproductive. > > > > Then maybe you also know how to force the curses libraries not to look > > there? Again, this is not an Emacs problem. > > It's an Emacs problem only in that a bit of Emacs code needs to be added > to force the curses libraries not to look there. Does it? From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 03 16:05:34 2025 Received: (at 79124) by debbugs.gnu.org; 3 Aug 2025 20:05:34 +0000 Received: from localhost ([127.0.0.1]:45872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiexZ-0006Pt-LM for submit@debbugs.gnu.org; Sun, 03 Aug 2025 16:05:34 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:49172) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uiexX-0006PU-0t for 79124@debbugs.gnu.org; Sun, 03 Aug 2025 16:05:31 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id CE6FE3C0149D0; Sun, 3 Aug 2025 13:05:24 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id hw3WiPC6E72J; Sun, 3 Aug 2025 13:05:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id A4B3B3C0149D1; Sun, 3 Aug 2025 13:05:24 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu A4B3B3C0149D1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754251524; bh=mUNXYCUwr5aj/90/0/V+0dbhxIKs+VKREURL3e9Q9Rc=; h=Message-ID:Date:MIME-Version:To:From; b=bZU+qGScum+SWmIjq8bZ+PT0GeiQMQieRowsCxVt4nQEyU7yJouVECKGP7fX0Ffcw /s2cGUYy+pw7aY4Xdc0TDey31q+AYYPUyB0mZDnLtaPBSKNkFq8rWv046Xq9fYvcVE DvLYB/Bd9zDL6RXwz2JxXDJjWOJNVFdHteq0qJyKuxEk8DCyoWK58UoZaEEpp4KhE6 rlu8sI0UtrZ/l98Rnp5jK5Ziin3uI4AM52JzmzTQ5d2hCvpyuqA2b/SvPGBb18hjDg 2OgYOc53wnVRjGdcWsYYwgWI666+LYK4aPyvhKvQ0gwyqNBthJMl7z5BZgo7nk3OWr ayn/LX5e1lPXw== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id DmBbsrzVDYsY; Sun, 3 Aug 2025 13:05:24 -0700 (PDT) Received: from penguin.cs.ucla.edu (unknown [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 7D24D3C0149D0; Sun, 3 Aug 2025 13:05:24 -0700 (PDT) Message-ID: Date: Sun, 3 Aug 2025 13:05:24 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <864iuoxu7x.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-08-03 09:09, Eli Zaretskii wrote: > I don't know what exactly happened in your case, and you never > described all of those details. I'm telling you what Emacs is > programmed to do. Emacs doesn't do what you say it's programmed to do. Here are more details. I started with Emacs master (current commit c935b68bed174386f46dec6be525a23397a4b5f8) on Ubuntu 25.04 x86-64. I then ran this: ./configure --with-native-compilation --prefix=/tmp/prefix make install mkdir test-directory cd test-directory HOME=/nodir PATH=/tmp/prefix/bin:/usr/bin strace -o tr emacs -nw I then interacted with the Emacs session for a bit, doing what I normally do. I created subshells, ran M-x hanoi (OK, this was just for fun; I normally don't do that :-), ran M-x compile, ran version control, etc. Everything worked except for the spurious diagnostics I mentioned in earlier email. I eventually typed C-x C-c to exit. When I examined 'tr' afterwards, I saw that all accesses to /nodir and to files under /nodir failed, almost all due to ENOENT. The one exception was a mkdir("/nodir",0777) failing due to EACCES. None of these issues mattered, other than the spurious diagnostics which should be easy to suppress with a new option. > For some value of "fine". Since we don't know what happened (which > files it tried to compile, if it tried, and where, if anywhere, it > wrote the *.eln files), we also don't know exactly what kind of > "working Emacs" you got as result. That it succeeded to run some > simple commands doesn't necessarily mean it's a healthy session. > Maybe it is, maybe it isn't. I would not be surprised if something would break if Emacs does not access user-specific files, just as some things already break if with -Q or -D. The fact remains, though, that in practice Emacs is quite useful without accessing user-specific files. It is useful for many kinds of tests, for people who want reproducible tests. It's even useful for ordinary work. >> this is better for testing, as test results do not rely on the >> contents of the user's home directory. > > Then your problem is solved, and we can stop this discussion My problem is definitely not solved, because this sort of thing is a significant hassle for people like me who want to do reproducible tests. It's a matter of priorities. If we want Emacs to be easy to test reproducibly, there's a real need for improvement here. If we think this sort of testing is unimportant, then indeed we should stop this discussion. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 04 01:14:05 2025 Received: (at submit) by debbugs.gnu.org; 4 Aug 2025 05:14:05 +0000 Received: from localhost ([127.0.0.1]:48195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uinWP-0006Qt-2t for submit@debbugs.gnu.org; Mon, 04 Aug 2025 01:14:05 -0400 Received: from lists.gnu.org ([2001:470:142::17]:57362) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uinWM-0006Q4-Kx for submit@debbugs.gnu.org; Mon, 04 Aug 2025 01:14:03 -0400 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 1uinWF-0008UA-HH for bug-gnu-emacs@gnu.org; Mon, 04 Aug 2025 01:13:55 -0400 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uinWB-0002fV-T1 for bug-gnu-emacs@gnu.org; Mon, 04 Aug 2025 01:13:54 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1uinW7-0004e3-Cs for bug-gnu-emacs@gnu.org; Mon, 04 Aug 2025 07:13:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Rudolf Schlatte Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate Date: Mon, 04 Aug 2025 07:13:42 +0200 Message-ID: References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:/uzxo0zE1U156kNgJ8efaKDZ8SA= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: submit 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: -1.0 (-) Paul Eggert writes: >>> this is better for testing, as test results do not rely on the >>> contents of the user's home directory. [...] > It's a matter of priorities. If we want Emacs to be easy to test > reproducibly, there's a real need for improvement here. If we think > this sort of testing is unimportant, then indeed we should stop this > discussion. You probably are already aware, but (if my understanding is correct) the code that is tested with a non-existent or non-writable home directory is byte-code interpreted, whereas with a writable home directory the code that is run is natively compiled. So the tests will test something subtly different than what end users will run. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 04 08:23:46 2025 Received: (at 79124) by debbugs.gnu.org; 4 Aug 2025 12:23:46 +0000 Received: from localhost ([127.0.0.1]:49618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiuED-0001mh-PX for submit@debbugs.gnu.org; Mon, 04 Aug 2025 08:23:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52150) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uiuEB-0001mM-Sf for 79124@debbugs.gnu.org; Mon, 04 Aug 2025 08:23:44 -0400 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 1uiuE4-0001sV-NV; Mon, 04 Aug 2025 08:23:37 -0400 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=voOcDaGyG+e65CL/lEKJQqdav1OfnpUYsGUTqIaBz/o=; b=CZA4sco2yryu YQPqu8XF8t7fqeb+07Luxap4NOCAwughAVH9KcSb3yIc5Tp9ZJ4hIikT7MdHZWQOJql6/DHvCPIFu OdGITjM/m2vpG3pTdDk/4cJr+zAOFE5an+EVNrMJOE0gbWlA1qCnF3saBHJF6kqxRs15MomjuM2uq LGPzzcyZqzLDzawBXGaHCo/D++HaRRLOPLqihw/PT2fUlkJn+1weTxepeq8MxvnxBsNuqG1aK2sGX TIrqBGu8evPtEMY/ZkKDd3q6DTpGIrE+d5/gAZLq2Da1x3hi0QKW8JBvkUNgnPBf/NvlsLxs/ZbC8 sw59jqSwT3OobPz0JN353Q==; Date: Mon, 04 Aug 2025 15:22:55 +0300 Message-Id: <86o6svwa1s.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Sun, 3 Aug 2025 13:05:24 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Sun, 3 Aug 2025 13:05:24 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-08-03 09:09, Eli Zaretskii wrote: > > > I don't know what exactly happened in your case, and you never > > described all of those details. I'm telling you what Emacs is > > programmed to do. > > Emacs doesn't do what you say it's programmed to do. > > Here are more details. I started with Emacs master (current commit > c935b68bed174386f46dec6be525a23397a4b5f8) on Ubuntu 25.04 x86-64. I then > ran this: > > ./configure --with-native-compilation --prefix=/tmp/prefix > make install > mkdir test-directory > cd test-directory > HOME=/nodir PATH=/tmp/prefix/bin:/usr/bin strace -o tr emacs -nw > > I then interacted with the Emacs session for a bit, doing what I > normally do. I created subshells, ran M-x hanoi (OK, this was just for > fun; I normally don't do that :-), ran M-x compile, ran version control, > etc. Everything worked except for the spurious diagnostics I mentioned > in earlier email. I eventually typed C-x C-c to exit. > > When I examined 'tr' afterwards, I saw that all accesses to /nodir and > to files under /nodir failed, almost all due to ENOENT. The one > exception was a mkdir("/nodir",0777) failing due to EACCES. None of > these issues mattered, other than the spurious diagnostics which should > be easy to suppress with a new option. How does this mean that "Emacs doesn't do what you say it's programmed to do"? I feel there's some huge misunderstanding here. Your experiment indicated that Emacs accesses the non-existent home directory. Naturally, all of those accesses failed, but if the directory existed, Emacs would have used it. Now, if setting HOME to a non-existent directory gives you what you want, then we can stop this discussion and conclude that your use case has a satisfactory solution. I thought, perhaps mistakenly, that you wanted to prevent Emacs from accessing the home directory when that directory did exist, and I therefore tried to explain why Emacs does access it for the purposes of native-compilation needed at startup, and what it does when it accesses the home directory. If these accesses are to be avoided when the home directory exists, the few relevant variables need to be changed from their defaults early enough during startup, and if that is not enough, only code changes (which I'm very unhappy to make) could do what you want. I hope this clarifies the situation. > > For some value of "fine". Since we don't know what happened (which > > files it tried to compile, if it tried, and where, if anywhere, it > > wrote the *.eln files), we also don't know exactly what kind of > > "working Emacs" you got as result. That it succeeded to run some > > simple commands doesn't necessarily mean it's a healthy session. > > Maybe it is, maybe it isn't. > > I would not be surprised if something would break if Emacs does not > access user-specific files, just as some things already break if with -Q > or -D. I'm talking about much more subtle issues, like the need to compile trampolines required in some cases. Maybe what you do doesn't need that, but in the past we had problems with disabling native compilation when trampolines were involved, so we added a special variable to do that safely. > The fact remains, though, that in practice Emacs is quite useful without > accessing user-specific files. It is useful for many kinds of tests, for > people who want reproducible tests. It's even useful for ordinary work. Once again, if directing HOME to a non-existent directory satisfies your needs, that's fine by me, and we don't need to continue this argument. > >> this is better for testing, as test results do not rely on the > >> contents of the user's home directory. > > > > Then your problem is solved, and we can stop this discussion > > My problem is definitely not solved, because this sort of thing is a > significant hassle for people like me who want to do reproducible tests. > > It's a matter of priorities. If we want Emacs to be easy to test > reproducibly, there's a real need for improvement here. If we think this > sort of testing is unimportant, then indeed we should stop this discussion. If the above means that directing HOME to a non-existent directory is not a satisfactory solution for this case, please explain why not: AFAIU, this does allow reproducible testing. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 04 09:02:08 2025 Received: (at 79124) by debbugs.gnu.org; 4 Aug 2025 13:02:08 +0000 Received: from localhost ([127.0.0.1]:49687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiupL-0003lW-Ky for submit@debbugs.gnu.org; Mon, 04 Aug 2025 09:02:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53430) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uiupI-0003kt-Eu for 79124@debbugs.gnu.org; Mon, 04 Aug 2025 09:02:05 -0400 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 1uiupC-0001e5-ME; Mon, 04 Aug 2025 09:01:58 -0400 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=S+WGiUmeO6/J/M8FuipTt01wDFYPYxwfVw74PjCWTMQ=; b=R/d3o9hO+vML 9ojVCcFu/rd3Vgip3LOByvhfRdzxB1awn8Z2tabcfEptSH+SVvsWH9JW+uBtk4zTae50N20amGqno 0mm8q7rTkNMg1748iVU/aqw0vkwU5p+EKxt2+IBP9awacUt2m1lRH8phsUsh8kKeUMtZN/+ZjxTsb tE973ZEc1O3CJQxip3DRgedw3x+7ghsTdXxBdQ0GqeMheVtr21ZihkFxz7hTtP1s8nXGlBGqL/fcT v0MwNbK3aoQ1mRWw46dMVFnHFAKVa0vxiMZjv5Sov0i8n3Bztc+aHrXy4v4lEI3JwvqJJIyw2pDTW b67Rj+vA37DDzhfWbwMapA==; Date: Mon, 04 Aug 2025 16:01:55 +0300 Message-Id: <86jz3jw88s.fsf@gnu.org> From: Eli Zaretskii To: Rudolf Schlatte In-Reply-To: (message from Rudolf Schlatte on Mon, 04 Aug 2025 07:13:42 +0200) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: 79124@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 (---) > From: Rudolf Schlatte > Date: Mon, 04 Aug 2025 07:13:42 +0200 > > Paul Eggert writes: > > > It's a matter of priorities. If we want Emacs to be easy to test > > reproducibly, there's a real need for improvement here. If we think > > this sort of testing is unimportant, then indeed we should stop this > > discussion. > > You probably are already aware, but (if my understanding is correct) the > code that is tested with a non-existent or non-writable home directory > is byte-code interpreted, whereas with a writable home directory the > code that is run is natively compiled. So the tests will test something > subtly different than what end users will run. Yes, this is another downside of suppressing native compilation in a build that's supposed to use it in production. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 04 10:12:29 2025 Received: (at 79124) by debbugs.gnu.org; 4 Aug 2025 14:12:30 +0000 Received: from localhost ([127.0.0.1]:52285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uivvR-0008LE-DB for submit@debbugs.gnu.org; Mon, 04 Aug 2025 10:12:29 -0400 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:41007) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uivvP-0008Kz-G0 for 79124@debbugs.gnu.org; Mon, 04 Aug 2025 10:12:28 -0400 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-459ddb41887so698435e9.0 for <79124@debbugs.gnu.org>; Mon, 04 Aug 2025 07:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754316741; x=1754921541; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FrRCerx12DKBm+nAzYhC3B4c/gWOCSE8PjPduXfqAM8=; b=RcuGp/LThyflm8/6rYb7Ftd+18yuP8r65FMYB2I2xPNnzqMBMi5SR4bQeuhCMvWutn bhaL+9jqyCvyvQwz8psImDai0GrD03Tlh5rHeDIg33Ygl/1c9mv9Hyxl6tvV6fnBzSTT BCMfhFkUoL9Gr12keXyLQuZ3BQ3x3rGJ1142vbMuKqero0I3mY7TrhE1I5lHxAj0P+zz y4WiJOD2/XqPsYObdtVHPfDoDOLoFsmNV/pAbRZW4wUidgHblvJCcOIIMIDtmIgvhX7S BhZwDjCr+LF18qm1gDLkPtlxZHUS8Vxahkn2dWTmuhn+2AQeEAzXi4VHbKHGvK0Ciha5 e8Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754316741; x=1754921541; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FrRCerx12DKBm+nAzYhC3B4c/gWOCSE8PjPduXfqAM8=; b=kRvcubplSBuQ10GhKXEs3il+FUkJBubFU47dek7xpl+2gFLQdQZtFs/FAm2ma0CbaO 4uILMeaekd+gnnDZHBFjI7rvIXn8nSwMaxUdOS7o5I4V8MsEOjRz9RT0CkYneSqEc8ZG Hv6I7krB3mW7hwMzkNO8ucZKg9d9O/XrDyNt4kotoECItw8Q1HMvEnQhUtrRMVTtmqP1 Jo4EjyTzT2Mw4YpuQv3grNMRa/1h+Shl8sIt/YgNfwKN6VnNLFqHNX/OKqipA/YlE9bQ PofjBna5SSCPXSL5AEPAKxuS6zKF1L0xvlMuWM5xXUXYUl+Rq5Oune5e5b0oqKl1q2CY umuw== X-Forwarded-Encrypted: i=1; AJvYcCV1qRrlJLILwnLQFmuhOA+MOsVq8FusQg+w6FYvCwG7qUaLAQfV6WL5UK5c5hFO296mUKlm6w==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yypg1cv5aD6hDwSUAWOqcQD7shV+TFnoohUcMXizbqU+43Ts3IP N6CExcVq5XseemzPtfBTFGg6cP1Z6xU8+SEgL7Ltl4aceIXnWzQ6uRaUvTIx3zlWVdL9cwW2f40 IgPRVu/NS2bF2t3tDi9cbwLPTltLIIICd7o4l X-Gm-Gg: ASbGncvrVXoriC1aSg/ZkZx9zE3CvF0gY90EqndVcj7KgR7I5alPXYsr10/1cJd9QtL qm6CauTxwxE9aCYqtxZmnLYOarRf2m2taE7Tu074rYpWPf1CMKHf8xmMEYqJ2gXpxfKpktdQt3D hdnRZWXlZ+OzFkr3PJLTyBvOKTt8hOgUtm9p5HxkMhdgoMun5Y0tZUgU4ugAJaD5Bd8JOqeAZXg Uzm811D3HNgifkUV2UWjfpMv6JCDs873EsEnYE= X-Google-Smtp-Source: AGHT+IELJvQ08/2sTflEmHFJLooQ9ihyS9oQ7I6QSa5qcL8lzQeMj00nZ5CKKrYiTLTb1q1NCarwvrr3qo4J8rm5MXs= X-Received: by 2002:a05:600c:3f12:b0:455:f12f:e3fc with SMTP id 5b1f17b1804b1-458b69c7d05mr33680345e9.2.1754316740491; Mon, 04 Aug 2025 07:12:20 -0700 (PDT) MIME-Version: 1.0 References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86jz3jw88s.fsf@gnu.org> In-Reply-To: <86jz3jw88s.fsf@gnu.org> From: Lynn Winebarger Date: Mon, 4 Aug 2025 10:12:09 -0400 X-Gm-Features: Ac12FXzgB-KIttovEWLJcyM_N6PCh1qSynFAf-va17MdHh_TuJiVI4iyLMwskcs Message-ID: Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000023fd0f063b8ab2c9" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: 79124@debbugs.gnu.org, Rudolf Schlatte 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: -1.0 (-) --00000000000023fd0f063b8ab2c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 4, 2025, 10:00=E2=80=AFAM Eli Zaretskii wrote: > > From: Rudolf Schlatte > > Date: Mon, 04 Aug 2025 07:13:42 +0200 > > > > Paul Eggert writes: > > > > > It's a matter of priorities. If we want Emacs to be easy to test > > > reproducibly, there's a real need for improvement here. If we think > > > this sort of testing is unimportant, then indeed we should stop this > > > discussion. > > > > You probably are already aware, but (if my understanding is correct) th= e > > code that is tested with a non-existent or non-writable home directory > > is byte-code interpreted, whereas with a writable home directory the > > code that is run is natively compiled. So the tests will test somethin= g > > subtly different than what end users will run. > > Yes, this is another downside of suppressing native compilation in a > build that's supposed to use it in production. > For reproducible testing of anything other than the support of on-demand native compilation, the tester should build two versions of emacs. The first --with-native-compilation=3Dno, the second with --with-native-compilation=3Daot. Then the use of byte- or native code will be deterministic even if HOME doesn't exist. Lynn --00000000000023fd0f063b8ab2c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 4, 2025, 10:00=E2=80=AFAM El= i Zaretskii <eliz@gnu.org> wrote:=
> From: Rudo= lf Schlatte <rudi@constantly.at>
> Date: Mon, 04 Aug 2025 07:13:42 +0200
>
> Paul Eggert <eggert@cs.ucla.edu> writes:
>
> > It's a matter of priorities. If we want Emacs to be easy to t= est
> > reproducibly, there's a real need for improvement here. If we= think
> > this sort of testing is unimportant, then indeed we should stop t= his
> > discussion.
>
> You probably are already aware, but (if my understanding is correct) t= he
> code that is tested with a non-existent or non-writable home directory=
> is byte-code interpreted, whereas with a writable home directory the > code that is run is natively compiled.=C2=A0 So the tests will test so= mething
> subtly different than what end users will run.

Yes, this is another downside of suppressing native compilation in a
build that's supposed to use it in production.

For reproducible testing = of anything other than the support of on-demand native compilation, the tes= ter should build two versions of emacs.=C2=A0 The first --with-native-compi= lation=3Dno, the second with --with-native-compilation=3Daot.=C2=A0 Then th= e use of byte- or native code will be deterministic even if HOME doesn'= t exist.

Lynn

--00000000000023fd0f063b8ab2c9-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 04 10:16:40 2025 Received: (at 79124) by debbugs.gnu.org; 4 Aug 2025 14:16:40 +0000 Received: from localhost ([127.0.0.1]:52292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uivzT-00007v-H2 for submit@debbugs.gnu.org; Mon, 04 Aug 2025 10:16:40 -0400 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:41537) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uivzQ-00007c-SD for 79124@debbugs.gnu.org; Mon, 04 Aug 2025 10:16:37 -0400 Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3b77dece52eso465930f8f.2 for <79124@debbugs.gnu.org>; Mon, 04 Aug 2025 07:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754316991; x=1754921791; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sifytRnG8WxWJVhkhJuXK+sRFfbbicZ2oDpcELgoiYE=; b=ZJEc6Y3Lg48AFdvHBfflMbH1Z4NYZ/JX6rHcG7YCTWcEDqMeZhn2B0f9MVLKtTY25q XV+zn/kxK7lcQHCyiJf24izuC+/WhtMQEvIxNfCtyk5CAbMf7JFeVJThm3cZHxbLBT2/ XgHyRSHcM0cWbFug/3KOdNfhCwcWNwC7oswSD9QQ1FCsFWUFUwqFmYX5Fo5nIjtmazFc KDSjvTOmePEPXw8AAG5IFR56o8st/LgsmC7GlxsoW8zZwJrCFspAZE6jzgpYnwszgHFQ vMMpS54OtHgACKbUpVGLsuFYJqc3liWuWHMKT9Ayhh09rqMIoFxs4UUX++PoEXBmFN8k A+tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754316991; x=1754921791; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sifytRnG8WxWJVhkhJuXK+sRFfbbicZ2oDpcELgoiYE=; b=E2XQKOHhcKNAGpBbsdY1+SRL2LQO12j47DOLJ3LN3CZu04lAqzc7G6RA08XMA/nqA3 nJput+BOdAn022Ss5xvScz7oVBEIOC7EaGasFSo7a4uDE3AWhX88kKDGHncJYSezHbmV xsGceIfkFjMCIdfdto+5HxXzHC24dz28S77nqXIPGAgi/h6oExsCmLf9fn7UnpfdT9Ik bdhqqHZ4+Anm5ZRlUHnsKREcizwSQa0q6G4I3p5vkEp/GWx+wziGZ8Crd5As+EaqOxVD O8FPPnl20hklFIZ4LKqbu0l2Gx0zeyKoHa9O+4qTeNrOtaukTVf7cFWuM31orLluMQHm beaQ== X-Forwarded-Encrypted: i=1; AJvYcCVFtvM+nULPYyZ9DZSnP4cLQJHZmD3Hy80pjspkwG9Waakvl+KpxWGfRt788Sr6Ah1702DEgw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxouYIHP5NFA1GwW1Ov97Eq/BC70B1lY3r0DmT1Hpl8MI6oRlaf kTe8DIGkuu2s4jHooqK8IUqia3UWFNE/JTMGjXt/FyjSHlf9l8mUbh9YybC5OAUVLBmlcrJXQbu IG5ATpQlnnTJMN7nlDofsRN5Zvt7/clM= X-Gm-Gg: ASbGncsFnYhn8szwD/MHupA0tG2EiVkjn4fPe8SA+ZoiVfVex2FF9o+rb2sB83N0Zka M3yP/o+GIL0Kn+QRwebeY72AC1rZ2P84AO1dlbVIM6ORSPDlScs6ALij3o+xt8pvJr3Ba57LqXs JmBY6NZlhBemmGlgYa7SVFEHEJuKO0e7D8vfcoUwm/SzETW1Y7UaSF7d77+3RpC8rFVx1gTh1+S 7K+PXBhNT92y+DXWKpvH97rcjE/rTjwmWFaU88= X-Google-Smtp-Source: AGHT+IFtbWmvAeZLYhn0vSdA8XDSapK1a/3FPvXiLCZXyXT5E56naZPwKoPgOI6eYbSTYJXtr9FJ516vDgb64+GWD1g= X-Received: by 2002:a5d:5d0f:0:b0:3b8:d360:336b with SMTP id ffacd0b85a97d-3b8d94c9e86mr2995127f8f.14.1754316990410; Mon, 04 Aug 2025 07:16:30 -0700 (PDT) MIME-Version: 1.0 References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86jz3jw88s.fsf@gnu.org> In-Reply-To: From: Lynn Winebarger Date: Mon, 4 Aug 2025 10:16:17 -0400 X-Gm-Features: Ac12FXxycpTgDyE6bVP5ir0WsoBiTQxGZGzEO9nHLmOe5sRoMI-RQiBlxRPv0EI Message-ID: Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000097884063b8ac157" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: Paul Eggert , 79124@debbugs.gnu.org, Rudolf Schlatte 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: -1.0 (-) --000000000000097884063b8ac157 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My response below is really for Paul, so I've added him back to the cc list= . On Mon, Aug 4, 2025, 10:12=E2=80=AFAM Lynn Winebarger = wrote: > On Mon, Aug 4, 2025, 10:00=E2=80=AFAM Eli Zaretskii wrote: > >> > From: Rudolf Schlatte >> > Date: Mon, 04 Aug 2025 07:13:42 +0200 >> > >> > Paul Eggert writes: >> > >> > > It's a matter of priorities. If we want Emacs to be easy to test >> > > reproducibly, there's a real need for improvement here. If we think >> > > this sort of testing is unimportant, then indeed we should stop this >> > > discussion. >> > >> > You probably are already aware, but (if my understanding is correct) t= he >> > code that is tested with a non-existent or non-writable home directory >> > is byte-code interpreted, whereas with a writable home directory the >> > code that is run is natively compiled. So the tests will test somethi= ng >> > subtly different than what end users will run. >> >> Yes, this is another downside of suppressing native compilation in a >> build that's supposed to use it in production. >> > > For reproducible testing of anything other than the support of on-demand > native compilation, the tester should build two versions of emacs. The > first --with-native-compilation=3Dno, the second with > --with-native-compilation=3Daot. Then the use of byte- or native code wi= ll > be deterministic even if HOME doesn't exist. > > Lynn > > --000000000000097884063b8ac157 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My response below is really for Paul, so I've ad= ded him back to the cc list.

On Mon, Aug 4, 2025, 10:12=E2=80=AFAM Lynn Wineba= rger <owinebar@gmail.com> wrote:
On Mon, Aug 4, 2025, 10:00=E2=80=AF= AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Rudolf Schlatte <rudi@constantly.at>
> Date: Mon, 04 Aug 2025 07:13:42 +0200
>
> Paul Eggert <eggert@cs.ucla.edu> write= s:
>
> > It's a matter of priorities. If we want Emacs to be easy to t= est
> > reproducibly, there's a real need for improvement here. If we= think
> > this sort of testing is unimportant, then indeed we should stop t= his
> > discussion.
>
> You probably are already aware, but (if my understanding is correct) t= he
> code that is tested with a non-existent or non-writable home directory=
> is byte-code interpreted, whereas with a writable home directory the > code that is run is natively compiled.=C2=A0 So the tests will test so= mething
> subtly different than what end users will run.

Yes, this is another downside of suppressing native compilation in a
build that's supposed to use it in production.

For reproducible testing = of anything other than the support of on-demand native compilation, the tes= ter should build two versions of emacs.=C2=A0 The first --with-native-compi= lation=3Dno, the second with --with-native-compilation=3Daot.=C2=A0 Then th= e use of byte- or native code will be deterministic even if HOME doesn'= t exist.

Lynn

--000000000000097884063b8ac157-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 04 13:19:22 2025 Received: (at 79124) by debbugs.gnu.org; 4 Aug 2025 17:19:22 +0000 Received: from localhost ([127.0.0.1]:52575 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiyqI-0000vy-9k for submit@debbugs.gnu.org; Mon, 04 Aug 2025 13:19:22 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:35120) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uiyqF-0000ve-H0 for 79124@debbugs.gnu.org; Mon, 04 Aug 2025 13:19:20 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 385B43C0149E2; Mon, 4 Aug 2025 10:19:13 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id XupPATXATf4j; Mon, 4 Aug 2025 10:19:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 0FB363C0149E3; Mon, 4 Aug 2025 10:19:13 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 0FB363C0149E3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754327953; bh=BZ9K9Xv9lNPcHBzep64DunxM70HPb/b5dOz4xGZW4ZY=; h=Message-ID:Date:MIME-Version:To:From; b=LJyeelfcRn/qPtreM1TPZLBq6epFdUnkyDk0Fym5UhScnScEzBOf9YGpuMLYm5gLm 4XWBPSp1c6/4K2byZc9E8CPTg4D60a3bqXN7Ct+Dy/FQA9o93CRpDdaV2eXny3nBPq 1KhtyNMCqZiesbNVz+bakrUF7TfUw+bEjGWCZqtUFbeoXqqdQ1o8xptKbkRazBnz/V xr7rUEo0ANF7/1nuzmnVuWSlsa9/NvHzrVaApIUbSW6Sece3C0pFetBcjiqprjXxdI ja5o/RVzibZzxveaPiwK0IzvzO/V7azwEVQVf/eZUExb8zgGUNBKMmUunb6olP3pFO W8CIUed4MfqYA== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id Oe8pORv7yiam; Mon, 4 Aug 2025 10:19:12 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id DB5C43C0149E2; Mon, 4 Aug 2025 10:19:12 -0700 (PDT) Message-ID: Date: Mon, 4 Aug 2025 10:19:12 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86o6svwa1s.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-08-04 05:22, Eli Zaretskii wrote: > if setting HOME to a non-existent directory gives you what you want It doesn't, for several reasons. * Emacs outputs spurious diagnostics. It shouldn't. * It's a pain to communicate with other users when diagnosing. I should be able to tell them "run emacs -QQ". But currently I have to tell them something like "get a copy of the Emacs source, run './configure --prefix=$HOME/prefix --with-native-compilation=aot', run 'make install' (this may a long time; be patient), set HOME to a nonexistent directory whose parent directory is unwritable, then run $HOME/prefix/bin/emacs -Q except use the old HOME not the new one and make sure you are not a superuser, and ignore the following worrisome-looking diagnostics". If they make a single mistake (say, they run as root) the whole thing falls apart. This is so awkward and unfriendly that I won't even bother. * When using Emacs in this way, I can't edit my own files conveniently. I have to use tell Emacs a name like "~eggert/foo" where I should be able to say just "~/foo". There are probably other reasons, these are just off the top of my head. > I'm talking about much more subtle issues, like the need to compile > trampolines required in some cases. Although I don't know what those subtle issues are, I don't see what they have to do with accessing $HOME when Emacs starts up. If Emacs needs to read files under $HOME to compile trampolines (why?) and $HOME is off-limits, it can access files in /tmp like other programs do. > I thought, perhaps mistakenly, that you > wanted to prevent Emacs from accessing the home directory when that > directory did exist No, I just want Emacs to skip the user-specific configuration it normally does, so that I'm running a vanilla Emacs rather than a tailored Emacs. This helps make tests more reproducible. I don't want to prevent all accesses to my home directory. The original intent of -Q was to have a convenient way to have Emacs run independently of user-specific configuration. If -Q has strayed away from that intent but we can't change its behavior for some backward compatibility concern, then we should have a new short option to do the original intent. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 04 14:14:42 2025 Received: (at 79124) by debbugs.gnu.org; 4 Aug 2025 18:14:42 +0000 Received: from localhost ([127.0.0.1]:52627 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uizhq-0003YI-Cz for submit@debbugs.gnu.org; Mon, 04 Aug 2025 14:14:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40422) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uizhl-0003Xv-So for 79124@debbugs.gnu.org; Mon, 04 Aug 2025 14:14:41 -0400 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 1uizhf-0003eO-MF; Mon, 04 Aug 2025 14:14:31 -0400 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=msRxlfO1mykfAeAhbL8m7Dq7BsfbexY8mGxMvZA6/FA=; b=J6sSETVC0FDj WtvzMl/8n0OMrlJVEaENkM+amcwghyDEoYNBBNg/SDc0VmKTeB5ChWT0j9KejKkwYiQoSLpgM1yr5 HiRL4c56+q17ZLa1d3Db3EzHKumqZamDCJnOQEDqfaRLpkaS4p+tgDRGCzFRJ71sqCXnQlQi5VYLL dQwvyBT8adEvdzt3K4FkUQFIuvWI/Bg2ArtgJgmB9BFemX2BaSH1UIE+mgFXgJqdZat+FdFAn6In1 1PIeK2CjGXTaftWxJi5SQWRiFbhr8Xym9elhYnWk38EVrDGzfvMQNojC9V4X5RJs8Xd0lhEv6VyY4 mnG9FLAc+/hEXwWeO2ihWw==; Date: Mon, 04 Aug 2025 21:14:08 +0300 Message-Id: <861pprvtsf.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Mon, 4 Aug 2025 10:19:12 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Mon, 4 Aug 2025 10:19:12 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > > I thought, perhaps mistakenly, that you > > wanted to prevent Emacs from accessing the home directory when that > > directory did exist > > No, I just want Emacs to skip the user-specific configuration it > normally does, so that I'm running a vanilla Emacs rather than a > tailored Emacs. Then accessing the eln-cache is not an issue for you, and we should just stop wasting each other's time. As I'm quite sure I said in my original response to your bug report. Because none of the *.eln files are user-specific configuration, precisely like the *.elc files on the user's machine aren't. > The original intent of -Q was to have a convenient way to have Emacs run > independently of user-specific configuration. If -Q has strayed away > from that intent but we can't change its behavior for some backward > compatibility concern, then we should have a new short option to do the > original intent. Then let's return to talking about the real problems: the loading of abbrevs and perhaps the auto-save-list files (not sure that the latter match the description of "user-specific configuration"). The rest of the accesses to the home directory are to load and/or write *.eln files, and have nothing to do with user configuration. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 04 16:09:10 2025 Received: (at 79124) by debbugs.gnu.org; 4 Aug 2025 20:09:10 +0000 Received: from localhost ([127.0.0.1]:52750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uj1Uc-0000hd-DO for submit@debbugs.gnu.org; Mon, 04 Aug 2025 16:09:10 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:43106) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uj1UZ-0000hM-Q6 for 79124@debbugs.gnu.org; Mon, 04 Aug 2025 16:09:08 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 8C2203C010852; Mon, 4 Aug 2025 13:09:01 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id o2GnLvyXeitR; Mon, 4 Aug 2025 13:09:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 61BA83C01085F; Mon, 4 Aug 2025 13:09:01 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 61BA83C01085F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754338141; bh=0WfSDPfAG7DmdD/kRz/Dim91drJzEhu8kQg6pDe65fs=; h=Message-ID:Date:MIME-Version:To:From; b=UAqpbRKi4OoKZadywkIcfFSLgvaxq0GojYbOPXbkHs8pTznL+aPRGMPBUnvj+pUy8 2z9VvH+E/CFHFU71pSpHm44EyTEYCJeDVV6cI4OSh0tVH7wuaWw0d629lMTTZKAupW sqi7FVSSR09ZpdH1TNB1vFIguuEqrJvbRhkzAfjEnWdknHXDc6AOBzl6VOYXOnU1pm Pq+0YNdHi2krNiQ45ZG2rHvgDejb4neWUjFd+/aK4ntQkfGFKTW0uwxQ+I8oTqxmS2 VF41q+cxd6gp5iEt21oekcCTpGZP47A6yTF6rZlbfhIV8WIM+gDt5bj7NL6qxLDHNz OmnVk5fUkGzAQ== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id q5KQuw9xMfvY; Mon, 4 Aug 2025 13:09:01 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 39D193C010852; Mon, 4 Aug 2025 13:09:01 -0700 (PDT) Message-ID: Date: Mon, 4 Aug 2025 13:09:00 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <861pprvtsf.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-08-04 11:14, Eli Zaretskii wrote: > none of the *.eln files > are user-specific configuration They are if the *.eln files are incorrect, which they may be for various reasons. A reproducible test should not be disrupted merely because the user's ~/.emacs.d/...macroexpand_0.eln is corrupt. > precisely like the *.elc files on the > user's machine aren't. Are you talking about *.elc files under ~/.emacs.d? In that case, yes, it should be just like *.eln files under ~/.emacs.d: neither kind of file should be read on startup in a reproducible test. I observed this issue only with *.eln files, and that is why I've been talking about *.eln files. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 05 07:19:28 2025 Received: (at 79124) by debbugs.gnu.org; 5 Aug 2025 11:19:28 +0000 Received: from localhost ([127.0.0.1]:53874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujFhX-00052V-Sc for submit@debbugs.gnu.org; Tue, 05 Aug 2025 07:19:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33292) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujFhV-000529-Q2 for 79124@debbugs.gnu.org; Tue, 05 Aug 2025 07:19:26 -0400 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 1ujFhP-0000kH-8Y; Tue, 05 Aug 2025 07:19:19 -0400 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=MeJUdgW8V3tQbi/WbdXlx6x4ZHx9jYE8qozhk1Hcv6Y=; b=LLuxpWCn90gJ 67VZZzhpgGmOUPbXdZ+Nqfq1VXYMZK8h8ukAqc4BcV4NOVZXPhtpTGh0Gb+ncMUPDiz/69apkOLER ukIB5Bn1c/K8JogmKyixPSC3wAN9Ee25/VQSA0h8+9q/bVrWITs+ZfrG367cDXA6oqG/+iChh8n1R d9S2K+XC4l3CzOGy2XVLqVQfFfVQGxS7k+HZLLinSFp47WfE8tmb7xdeZrOUFF6e8IXM+35+fHM31 fmC9oNKe2P63IZvDIg0Anwrd91qwz8WOChRrRd/mLxntMBn+9R/kB/pDqYatY5Zmxsb5YOIx7RCja jtQ/ayfnS/4oPdnzv63CWA==; Date: Tue, 05 Aug 2025 14:19:09 +0300 Message-Id: <86qzxquic2.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Mon, 4 Aug 2025 13:09:00 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Mon, 4 Aug 2025 13:09:00 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-08-04 11:14, Eli Zaretskii wrote: > > none of the *.eln files > > are user-specific configuration > > They are if the *.eln files are incorrect, which they may be for various > reasons. Please give examples for such reasons. AFAIR, you accepted the AOT build as a workaround for this problem, in which case I don't understand how the *.eln files compiled from the *.el files in the Emacs source tree are "kosher" when they are in the installation tree, but not if they are under ~/.emacs.c/eln-cache/. I also don't understand how are they different from *.elc files produced on the user's machine as part of the build and installed in the installation tree. > A reproducible test should not be disrupted merely because the > user's ~/.emacs.d/...macroexpand_0.eln is corrupt. Why would it be corrupt, but the same file under /usr/lib/emacs cannot be? > > precisely like the *.elc files on the > > user's machine aren't. > > Are you talking about *.elc files under ~/.emacs.d? In that case, yes, > it should be just like *.eln files under ~/.emacs.d: neither kind of > file should be read on startup in a reproducible test. I observed this > issue only with *.eln files, and that is why I've been talking about > *.eln files. The directory where these files live is not important. What's important is that they are produced from the stock Lisp sources of the Emacs distribution, which is what you presumably want to test. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 05 11:23:32 2025 Received: (at 79124) by debbugs.gnu.org; 5 Aug 2025 15:23:32 +0000 Received: from localhost ([127.0.0.1]:56714 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujJVj-0006do-Gc for submit@debbugs.gnu.org; Tue, 05 Aug 2025 11:23:31 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:48342) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujJVh-0006dV-F7 for 79124@debbugs.gnu.org; Tue, 05 Aug 2025 11:23:29 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 254DD3C01086C; Tue, 5 Aug 2025 08:23:23 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id OHsyfmGPSABR; Tue, 5 Aug 2025 08:23:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id F0EB53C0149C9; Tue, 5 Aug 2025 08:23:22 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu F0EB53C0149C9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754407403; bh=SskPYNHr/LzISQRkIz+BzUsBqJolA/P1/qg+wv7+8X4=; h=Message-ID:Date:MIME-Version:To:From; b=PTl5ieVFCsW9C7vDs5Tms92w2w0kT1J/TPQ1fIW+lS8k1VSQ7n/sqzCD/pfJJ8QIT G40ZaGN6cmFqZDyiuWofpmPZayb1RNpzMeBOhw3C9md7VvUQVQeHVKhiHE4gMXgZLX v6vT2W4/MsKW6gZuvwI5Gu7zcEZbW1RMv05EG99dRZMv9nfQmoK9N1rcsF4k3zb/sr 5XnLsfEpvDyhybGCVuRhinnsFnnLQV73sBU9faCocvSb2SPVopvWTBUA8MJZPo8AfR NPhngxwU4RAsOvB8Su9SUBiiYfR2D+f55wz4K6SWo5TXbp+9VCxemEvnpsNte1qtTo hwxdOokV8diXA== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id Z_6KRENoMAVn; Tue, 5 Aug 2025 08:23:22 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id C8C393C01086C; Tue, 5 Aug 2025 08:23:22 -0700 (PDT) Message-ID: <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> Date: Tue, 5 Aug 2025 08:23:22 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86qzxquic2.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-08-05 04:19, Eli Zaretskii wrote: > AFAIR, you accepted the AOT > build as a workaround for this problem, No, I didn't. I rejected it because it's too much of a pain to expect users to rebuild Emacs (in an especially-length process!) just to reproduce a bug. > I don't understand how the *.eln files compiled from the *.el files in the > Emacs source tree are "kosher" when they are in the installation tree, > but not if they are under ~/.emacs.c/eln-cache/. I'm assuming that Emacs was installed correctly (if not, all bets are off anyway). What I don't want to assume is anything in the user's home directory, because that can make tests irreproducible. >> A reproducible test should not be disrupted merely because the >> user's ~/.emacs.d/...macroexpand_0.eln is corrupt. > > Why would it be corrupt, but the same file under /usr/lib/emacs cannot > be? Could be many reasons. For example, maybe they backed up their home directory but then restored it incorrectly. Whatever the reason is, I don't want the user's home directory to affect the test. > The directory where these files live is not important. It is important, because I want the tests to depend only on the installed Emacs, not on the user's own files. That's a core part of making tests reproducible. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 05 12:02:16 2025 Received: (at 79124) by debbugs.gnu.org; 5 Aug 2025 16:02:16 +0000 Received: from localhost ([127.0.0.1]:56758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujK7D-00009I-EU for submit@debbugs.gnu.org; Tue, 05 Aug 2025 12:02:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50070) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujK78-000090-G7 for 79124@debbugs.gnu.org; Tue, 05 Aug 2025 12:02:13 -0400 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 1ujK72-00068c-C4; Tue, 05 Aug 2025 12:02:04 -0400 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=xo4CZxQrOULHCR1VFmdoNN+lmcE16LhFBAU0/+eIIvQ=; b=ZjrWILn6DRQQ VNO5PmrprH3D0v+12P3O2TFq78Bce5B91075z7tnGT7OPBUI7qHNhuQVeu8yxIJY6rdx4zgvL0AIU EQflInKGd6pWmawwqDXMtR7/etOU24rrdHvfTiw6S9TuqTkMkL4+erhIwj2FzvK8efuZNqxeet/zN 0A1Bj21CJ7XwV0uHikV6Kg7QgEp7GGRCcfBDDor0mYNayC3fjCq8aMsHxSF7LlqBPk3PfGWWS51S/ aUhxtzv8os7HA8dXkNzi4BrXfgqGmnWdonJBoNn2jYhhoBhDhFHjnL+FGiz4Mkv02/RDV6Ywmp2wR /P2de3M2teSiBC3q0BwN7A==; Date: Tue, 05 Aug 2025 18:55:03 +0300 Message-Id: <8634a5vk4o.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> (message from Paul Eggert on Tue, 5 Aug 2025 08:23:22 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Tue, 5 Aug 2025 08:23:22 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-08-05 04:19, Eli Zaretskii wrote: > > > AFAIR, you accepted the AOT > > build as a workaround for this problem, > > No, I didn't. I rejected it because it's too much of a pain to expect > users to rebuild Emacs (in an especially-length process!) just to > reproduce a bug. If the only problem is the pain, then you did accept it as the workaround. The effort to produce an AOT build is not relevant to this discussion, only the correctness of the resulting *.eln files is. Let's please not waste time on irrelevant tangents, and focus on the main issues. > > I don't understand how the *.eln files compiled from the *.el files in the > > Emacs source tree are "kosher" when they are in the installation tree, > > but not if they are under ~/.emacs.c/eln-cache/. > > I'm assuming that Emacs was installed correctly (if not, all bets are > off anyway). What I don't want to assume is anything in the user's home > directory, because that can make tests irreproducible. The same code which writes *.eln files in the AOT case writes them in the user's eln-cache directory. So either both are acceptable or both aren't. > >> A reproducible test should not be disrupted merely because the > >> user's ~/.emacs.d/...macroexpand_0.eln is corrupt. > > > > Why would it be corrupt, but the same file under /usr/lib/emacs cannot > > be? > > Could be many reasons. For example, maybe they backed up their home > directory but then restored it incorrectly. Whatever the reason is, I > don't want the user's home directory to affect the test. Whatever can happen with the user's home directory can also happen with the files in the directories of the installation tree. The *.eln files written into the user's eln-cache while compiling *.el files from the installation tree are for all practical purposes parts of the Emacs build, not parts of the user configuration. > > The directory where these files live is not important. > > It is important, because I want the tests to depend only on the > installed Emacs, not on the user's own files. That's a core part of > making tests reproducible. The files in ~/.emacs.d/eln-cache/ produced by compiling *.el files from the installation tree are part of the installed Emacs. They just live in a different directory. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 05 12:50:54 2025 Received: (at 79124) by debbugs.gnu.org; 5 Aug 2025 16:50:54 +0000 Received: from localhost ([127.0.0.1]:56827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujKsH-0002Z3-Sr for submit@debbugs.gnu.org; Tue, 05 Aug 2025 12:50:54 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:37540) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujKsD-0002Yi-Co for 79124@debbugs.gnu.org; Tue, 05 Aug 2025 12:50:51 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 273453C0149D0; Tue, 5 Aug 2025 09:50:43 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id C995NDI5M8SL; Tue, 5 Aug 2025 09:50:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id F2B4A3C0149D1; Tue, 5 Aug 2025 09:50:42 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu F2B4A3C0149D1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754412643; bh=tnfmC0tXRmaI9fyh5/RvWpJovAGCAzW4VBpUO5A0sJ0=; h=Message-ID:Date:MIME-Version:To:From; b=AVgW/GqkyFJQ2K02P2U4VeNm9YS0ohhTv0ARKSB5mUdDJOG1Awm0z7X9xXa4C5Ev7 gw7U9/lgJp0jhc2ZeqeNVT0eoPrraeYAMmx+yyxlLWFg98+iVLLatotfxe7grPIvqK HnL670jv4jOpws+YKzjvdKunZxz47/V8ypgwtELy2boiAkdGq5stykxMK3TXDL41xV Pb/61SWGpGFQm2r70/EOOhPkrs/UrNp2HSPyDzWBhAgCW0D3AeRer+bbP4KhPSAG4E emTKKmPjqDyK5OqZE+/4J/ufrGK79oUU2SbcG2vR1Wm9hy60Oxy5CkBi+5BTv8mFSf gWIJy6jf4d4sg== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id xoVl1-t0Mzgg; Tue, 5 Aug 2025 09:50:42 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id C536A3C0149D0; Tue, 5 Aug 2025 09:50:42 -0700 (PDT) Message-ID: <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> Date: Tue, 5 Aug 2025 09:50:42 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <8634a5vk4o.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-08-05 08:55, Eli Zaretskii wrote: > If the only problem is the pain, then you did accept it as the > workaround. This mischaracterizes what I wrote. I wrote that it "is so awkward and unfriendly that I won't even bother". It is unreasonable to expect bug-reporters to rebuild Emacs from scratch in a tricky procedure, and I do not accept this as a workaround. > Whatever can happen with the user's home directory can also happen > with the files in the directories of the installation tree. Also not correct in common situations where the installation files can be trusted where the home directory cannot. In most setups, installation files are readonly and set up by a trusted user, whereas the home directory is not. > The *.eln > files written into the user's eln-cache while compiling *.el files > from the installation tree are for all practical purposes parts of the > Emacs build, not parts of the user configuration. Not if the files were corrupted after being written. And there are other reasons they might not be the same in practice. > The files in ~/.emacs.d/eln-cache/ produced by compiling *.el files > from the installation tree are part of the installed Emacs. But that assumes that those files' contents are correct. An important part of testing is to check assumptions like that. Testing should not make unnecessary assumptions. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 05 13:52:41 2025 Received: (at 79124) by debbugs.gnu.org; 5 Aug 2025 17:52:41 +0000 Received: from localhost ([127.0.0.1]:56886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujLq5-0005N9-8R for submit@debbugs.gnu.org; Tue, 05 Aug 2025 13:52:41 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:47210) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujLq1-0005Mz-9x for 79124@debbugs.gnu.org; Tue, 05 Aug 2025 13:52:39 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=x28YhRQ/ Hrph5FwU2WqyDUMXeaTAGRGNVzbkG2gtNhA=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=PGnJK6Tbd+rcj5jUXI8BTsc/yDmQT/ 51CmwpbEqCKTFuZHOc5stfUJrfjw/rWTgj7sKUDaqIMEPGbwfPLXyDAQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=x28YhRQ/Hrph5FwU 2WqyDUMXeaTAGRGNVzbkG2gtNhA=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=z9b3kBunT8NfG9WsQUFIl86wbPi9ZaDBDVBs00 yImIw7IdxDMjQ+sa3qsS/QcioasCyNp+cY8xMJsvMVsztXB+TQQkRPhrUfhOTuYXxWJXCl TPEZU4GIB2/1tQpH+sFZzuOoHzTRRIA+UH77t3lhwjH36Kh2xTa2vYHY3FDVCZKq+vnwBj GMIZF3GOwArdv9xUFbCAj1TAt+YmadjG59TW/E24Tz1ljynveJiLifk/Ka21RJjEL0s6v+ vQ8RmME2NnRHbgrliXytOO2WGgoR+AH62cciPCmeMdOmonYMzzXPfmjuj1HhGke88203zt g9J26+mbvpnlsR3u3ezxsBhg== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 5dc6dc43 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 5 Aug 2025 19:52:35 +0200 (CEST) From: Manuel Giraud To: Paul Eggert Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate In-Reply-To: <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> References: <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> Date: Tue, 05 Aug 2025 19:52:34 +0200 Message-ID: <87a54d8xlp.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: Eli Zaretskii , 79124@debbugs.gnu.org, rpluim@gmail.com, rms@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: -1.0 (-) Paul Eggert writes: > On 2025-08-05 08:55, Eli Zaretskii wrote: > >> If the only problem is the pain, then you did accept it as the >> workaround. > > This mischaracterizes what I wrote. I wrote that it "is so awkward and > unfriendly that I won't even bother". It is unreasonable to expect > bug-reporters to rebuild Emacs from scratch in a tricky procedure, and > I do not accept this as a workaround. > >> Whatever can happen with the user's home directory can also happen >> with the files in the directories of the installation tree. > > Also not correct in common situations where the installation files can > be trusted where the home directory cannot. In most setups, > installation files are readonly and set up by a trusted user, whereas > the home directory is not. > >> The *.eln >> files written into the user's eln-cache while compiling *.el files >> from the installation tree are for all practical purposes parts of the >> Emacs build, not parts of the user configuration. > > Not if the files were corrupted after being written. And there are > other reasons they might not be the same in practice. > >> The files in ~/.emacs.d/eln-cache/ produced by compiling *.el files >> from the installation tree are part of the installed Emacs. > > But that assumes that those files' contents are correct. An important > part of testing is to check assumptions like that. Testing should not > make unnecessary assumptions. FWIW, I agree with this. But I don't know why something like this would not work: emacs -Q --init-directory=$(mktemp -d) Does the eln cache does not honor the init directory? -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 05 15:20:44 2025 Received: (at 79124) by debbugs.gnu.org; 5 Aug 2025 19:20:44 +0000 Received: from localhost ([127.0.0.1]:56989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujNDI-00014U-1w for submit@debbugs.gnu.org; Tue, 05 Aug 2025 15:20:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44234) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujNDE-00014E-W4 for 79124@debbugs.gnu.org; Tue, 05 Aug 2025 15:20:42 -0400 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 1ujND8-0000Wn-Uv; Tue, 05 Aug 2025 15:20:34 -0400 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=NLq80w03wAHZFD5XN89LjeBZa8NBzxogRSFIPgDW2xE=; b=cnxN3U+uoRGK 7FJhitu3lwoZdq2P7qyVxhOmS3R/5Sr8tCDbAxeavrB5DzgWTeZyjfl3aQoT4kIIJAzvPhCN9aKOE y8M0fBwR/F68Z6+cFWn61IliH7b56iEPbvSg1GRdmGgfHclXuFI9dLP7H4aCO3i5R5XcOrFYnsQXE PsUDmzCKJpp85hEWMUAF5fu68tU7D2r70O1f8EDQQsvk8Vlaa1pnB20ihxFueB+yOg1mWuc/5zvzH A25UL+OYQvnwMM5/1o56de/i16xeQNaYza3rY6fPxZE/Oqy8iJLKUylvTOt8dVk+BgkUtCmw88IZ6 X/sti644tDnqx8cTZpcQWg==; Date: Tue, 05 Aug 2025 22:19:45 +0300 Message-Id: <86wm7htw32.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> (message from Paul Eggert on Tue, 5 Aug 2025 09:50:42 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <868qk5x4ay.fsf@gnu.org> <87o6t1ahvg.fsf@gmail.com> <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Tue, 5 Aug 2025 09:50:42 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-08-05 08:55, Eli Zaretskii wrote: > > > If the only problem is the pain, then you did accept it as the > > workaround. > > This mischaracterizes what I wrote. I wrote that it "is so awkward and > unfriendly that I won't even bother". It is unreasonable to expect > bug-reporters to rebuild Emacs from scratch in a tricky procedure, and I > do not accept this as a workaround. Once again, I didn't say they should. I said that if the result of AOT build would be acceptable for this kind of testing, then so should be the results of JIT compilation of the same Lisp files into the same *.eln files, just because they are loaded from a different directory. > > Whatever can happen with the user's home directory can also happen > > with the files in the directories of the installation tree. > > Also not correct in common situations where the installation files can > be trusted where the home directory cannot. These files are not "home directory", they just live there. Emacs compiles them exactly as it does during an AOT build, it just does it in JIT manner, and it writes them under the home directory. That's all the difference between those two. > In most setups, installation files are readonly and set up by a > trusted user, whereas the home directory is not. We are talking about users, such as yourself, who run such tests. Those users are most probably building and installing their own Emacs. So they _are_ that trusted user, in both cases. > > The *.eln > > files written into the user's eln-cache while compiling *.el files > > from the installation tree are for all practical purposes parts of the > > Emacs build, not parts of the user configuration. > > Not if the files were corrupted after being written. The files can be corrupted in any place, not only in the home directory. Why do you trust the installed files to not be corrupt? > > The files in ~/.emacs.d/eln-cache/ produced by compiling *.el files > > from the installation tree are part of the installed Emacs. > > But that assumes that those files' contents are correct. Their contents are as correct as of the byte-compiled and natively-compiled files in the installation tree. They were produced from the same sources, likely by the same compiler. > An important part of testing is to check assumptions like > that. Testing should not make unnecessary assumptions. There are no assumptions here that are not present when you test the files from the installation tree. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 05 16:48:37 2025 Received: (at 79124) by debbugs.gnu.org; 5 Aug 2025 20:48:37 +0000 Received: from localhost ([127.0.0.1]:57071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujOaK-0005EN-Md for submit@debbugs.gnu.org; Tue, 05 Aug 2025 16:48:36 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:33288) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujOaI-0005E8-TE for 79124@debbugs.gnu.org; Tue, 05 Aug 2025 16:48:35 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 0939F3C010860; Tue, 5 Aug 2025 13:48:29 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id T0JEiyIakpit; Tue, 5 Aug 2025 13:48:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id D3E6A3C01086C; Tue, 5 Aug 2025 13:48:28 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu D3E6A3C01086C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754426908; bh=Z19n7VDWNpI/fWGq5NvJKSXqlujN8EhHsfNZs1mNliE=; h=Message-ID:Date:MIME-Version:To:From; b=XfnEL+UttAJplUos2+PzfUUR4fiRW/Rz53m/JxnDmV2wS2vMy9r2qidN4RpwIsQ4h V7WdFrcPDYn23P03KUHDr04dtQ3+Q7KAD3mtk0SiPZelWjrxDQLuvyWIDJC/VjqRLc vgfvp1yy3zlGgZnu1zvXovoLAf6DdZjAbGNiQiNftGUwRIsaHil4JJFGe8IAPnqCdI 5iNe1kbhVamP0I/akPpwjUU/tT6xCYiU0N83T9aDkPguSz261K3M9LijzZUtLOBvOP OstrLbAIiMDuYREUm/FVF4Xm4pRIIn4mA9ObLBx0sI1nNKJXcb1UrcKBr7sYGiwe08 On9AZWPAXxfLw== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 8IeioHLMu8q2; Tue, 5 Aug 2025 13:48:28 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id AFD4D3C010860; Tue, 5 Aug 2025 13:48:28 -0700 (PDT) Message-ID: Date: Tue, 5 Aug 2025 13:48:28 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <86wm7htw32.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86wm7htw32.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-08-05 12:19, Eli Zaretskii wrote: > These files are not "home directory", they just live there. Because they live in the home directory, they're subject to all the problems that any home-directory files can have, and those are problems that -Q (or -QQ if you prefer) are supposed to work around. It doesn't matter whether the files were last modified by Emacs or by some other program. >> In most setups, installation files are readonly and set up by a >> trusted user, whereas the home directory is not. > > We are talking about users, such as yourself, who run such tests. > Those users are most probably building and installing their own Emacs. No, I respond to bug reports (mostly not on this forum) from people who typically are not building and installing their own Emacs. They're running an Emacs that the system made available to them. > The files can be corrupted in any place, not only in the home > directory. Why do you trust the installed files to not be corrupt? Because the installed files are read-only, the user can't modify them, and so they are as trustworthy as the rest of the distro. This is standard practice on GNU/Linux and similar systems. I continue to be puzzled by the idea that -Q should read from $HOME/.emacs.d. If there's a reason for that behavior, we should add a flag -QQ that avoids reading from $HOME during startup. This would be a real win for a common use case, and it wouldn't hurt other uses. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 05 16:48:46 2025 Received: (at 79124) by debbugs.gnu.org; 5 Aug 2025 20:48:46 +0000 Received: from localhost ([127.0.0.1]:57075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujOaU-0005Ep-18 for submit@debbugs.gnu.org; Tue, 05 Aug 2025 16:48:46 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:33076) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujOaK-0005EC-Ov for 79124@debbugs.gnu.org; Tue, 05 Aug 2025 16:48:37 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 1F6E83C01086C; Tue, 5 Aug 2025 13:48:31 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id ZHRH3aZXHcCG; Tue, 5 Aug 2025 13:48:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id E9DB93C010873; Tue, 5 Aug 2025 13:48:30 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu E9DB93C010873 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754426911; bh=FsxCwTpxG19kgQY1w5M/PeXirYK7SA1ieKqtCqhZJbM=; h=Message-ID:Date:MIME-Version:To:From; b=Y2a/hxl8aUeg52q8wKZ8xJ24NkhXZY2plppNTmGck7SDm1xNimiSsAmihdR+AQBj7 5I6b9ksameZhs8Id115vGyU4+B4wwCKF/2RxR76zXwo5CF8LCwWAOL2C3LVWthyQ11 qSmJIq3zT8Oa+jAOaGO/6y3xrPC32QjS+lc1Zr42WzEEapD7fk5TfDoUvDY6VajEC8 g6xgGb7V44BSvWtdH/+dCA4lz3ZSNxZj+eEzhCrMJAhnxYOF3jUwOPa+Q7Vd3vMem3 QUOH/xtN7R3lM6uwb/kraZ/SopjGDKydavQyNLry/tIQnA5gwfFv160JK4LT6d+GzT IBQsZb89PkKtg== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id aq4U3xaN9ddx; Tue, 5 Aug 2025 13:48:30 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id BE1063C01086C; Tue, 5 Aug 2025 13:48:30 -0700 (PDT) Message-ID: Date: Tue, 5 Aug 2025 13:48:30 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Manuel Giraud References: <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <87a54d8xlp.fsf@ledu-giraud.fr> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <87a54d8xlp.fsf@ledu-giraud.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: Eli Zaretskii , 79124@debbugs.gnu.org, rpluim@gmail.com, rms@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: -1.0 (-) On 2025-08-05 10:52, Manuel Giraud wrote: > I don't know why something like this would > not work: > > emacs -Q --init-directory=$(mktemp -d) That leaves behind a directory in /tmp. Actually, it leaves two of them behind, one for a different reason; libgccjit creates it. Although these are not fatal objections, they're messes that we're better off without. Testing should be simple, not complicated. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 06 07:16:35 2025 Received: (at 79124) by debbugs.gnu.org; 6 Aug 2025 11:16:35 +0000 Received: from localhost ([127.0.0.1]:58233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujc8J-00040C-Bb for submit@debbugs.gnu.org; Wed, 06 Aug 2025 07:16:35 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:23559) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujc8F-0003zy-B0 for 79124@debbugs.gnu.org; Wed, 06 Aug 2025 07:16:33 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=yj0id2T7 NgP4DhAwBwgMFPFwezsR3Spiaizy3VMoRc4=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=AcRhy2ujm0dXMX4fMcb9AEsh8b2uA7 N0pympSeV3oSZkl5HQ3m7aGLFuQ7podZ+lxo25/rmAHV96AH3GatTTBw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=yj0id2T7NgP4DhAw BwgMFPFwezsR3Spiaizy3VMoRc4=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=vkUhiVJBgMf+Kcf/qANfP5/jgK6pG1EJcPtABP tU/gCF6ooqICx2o9ubEqz8kWfRVftcFTk5lQnB2MNQo8/LvE5amqYCT6i/q+4Zc2cYUPeb qxFyIqDo4AClQVa1sdTGQqKJ495zV6DE05btJ3MkromcmR0bM74Njcj7270YPjkJQjzViH 2bIAicBgPJ935rZDYjDIGNqEhM9KsluZbF9SAF003lAsn8J99ucrLbzgfvwSdWrKckSj1E RZF7a/QTEH3RHbxkUsbgYesDL8ouShgfW4s+7CtcToIpGYJryMEFSj+DwYMXougKTnzG2u jLeSvpXSk7i3ASzHDsJaGjpQ== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 0e25ef62 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 6 Aug 2025 13:16:29 +0200 (CEST) From: Manuel Giraud To: Paul Eggert Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate In-Reply-To: References: <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <87a54d8xlp.fsf@ledu-giraud.fr> Date: Wed, 06 Aug 2025 13:16:27 +0200 Message-ID: <875xf08zuc.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: Eli Zaretskii , 79124@debbugs.gnu.org, rpluim@gmail.com, rms@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: -1.0 (-) Paul Eggert writes: > On 2025-08-05 10:52, Manuel Giraud wrote: >> I don't know why something like this would >> not work: >> emacs -Q --init-directory=$(mktemp -d) > > That leaves behind a directory in /tmp. Yes I know. My idea was to first identify is this is sufficient to create an isolated environment for Emacs. > Actually, it leaves two of them behind, one for a different reason; > libgccjit creates it. Which directory does libgccjit create? > Although these are not fatal objections, they're messes that we're > better off without. Testing should be simple, not complicated. Yes of course. The second part of my idea is that maybe -Q could be a shortcut for "-q --no-site-file --no-splash --init-directory=$TMPDIR_SOMEWHERE_THAT_WOULD_BE_DELETED_WHEN_QUITTING" -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 06 08:35:22 2025 Received: (at 79124) by debbugs.gnu.org; 6 Aug 2025 12:35:22 +0000 Received: from localhost ([127.0.0.1]:58422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujdMX-0004qd-N1 for submit@debbugs.gnu.org; Wed, 06 Aug 2025 08:35:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45686) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujdMU-0004qL-Lx for 79124@debbugs.gnu.org; Wed, 06 Aug 2025 08:35:19 -0400 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 1ujdMO-0002rb-Ke; Wed, 06 Aug 2025 08:35:12 -0400 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=Nn0TD/SmQMaOlrDf9v+0VXLi05GhwzcLF7x4FZfwdfU=; b=gmn6t27ip2z7 YT/staZhjELwqU8Ee+sKGyZ+tXh0741Gmxx188dM/43BOjQrw9qTwR41eWt4iwn+/L3LumFbA6Xff wh+g3IBF3UIbUQee/rYMplL5EW5QVKW3OnIBz4kwFZFbVWMo+kLxRBXKYkB+zwt9uAgW51/6y0Ky6 meZAMtS39QKaPkm3LvJWiN7ZR7T987eRrWsXHiQ101NvCoJL+lVTUzc6DHzqEEj0HZHz+pF5Q4sxu 8AB13gStIkAMR6R2YYbA2J4P/GQv6uOQ/WmfkFHGeGJWu7K6kKcVvDyrh3RU2g1rtlPU3lhf+WDC9 SVf73IUm0BQZB/kD/iky6w==; Date: Wed, 06 Aug 2025 15:34:56 +0300 Message-Id: <86h5yktyq7.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Tue, 5 Aug 2025 13:48:28 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <86tt2tvgrf.fsf@gnu.org> <87jz3pae2h.fsf@gmail.com> <86seidvf76.fsf@gnu.org> <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <86wm7htw32.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Tue, 5 Aug 2025 13:48:28 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-08-05 12:19, Eli Zaretskii wrote: > > > These files are not "home directory", they just live there. > > Because they live in the home directory, they're subject to all the > problems that any home-directory files can have, and those are problems > that -Q (or -QQ if you prefer) are supposed to work around. It doesn't > matter whether the files were last modified by Emacs or by some other > program. > > >> In most setups, installation files are readonly and set up by a > >> trusted user, whereas the home directory is not. > > > > We are talking about users, such as yourself, who run such tests. > > Those users are most probably building and installing their own Emacs. > > No, I respond to bug reports (mostly not on this forum) from people who > typically are not building and installing their own Emacs. They're > running an Emacs that the system made available to them. > > > The files can be corrupted in any place, not only in the home > > directory. Why do you trust the installed files to not be corrupt? > > Because the installed files are read-only, the user can't modify them, > and so they are as trustworthy as the rest of the distro. This is > standard practice on GNU/Linux and similar systems. If you still insist on this, then we will have to agree to disagree. The solution we use in the test suite is to set HOME to a non-existent directory, so that's what I can suggest in your case. > I continue to be puzzled by the idea that -Q should read from > $HOME/.emacs.d. The reason is our decision that JIT-compiled Lisp files are written under the user home directory (and I don't think that decision was wrong). The other part of the puzzle is that it is not always possible to predict in advance what Lisp files will be automatically loaded at startup because they are needed by the startup code, so they couldn't all be natively-compiled in advance. > If there's a reason for that behavior, we should add a > flag -QQ that avoids reading from $HOME during startup. This would be a > real win for a common use case, and it wouldn't hurt other uses. As I explained, I'm not interested in adding yet another way of avoiding native-compilation, because what we have is versatile and complex enough. Sorry. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 06 09:08:07 2025 Received: (at 79124) by debbugs.gnu.org; 6 Aug 2025 13:08:07 +0000 Received: from localhost ([127.0.0.1]:58491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujdsE-0006Lr-PH for submit@debbugs.gnu.org; Wed, 06 Aug 2025 09:08:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59994) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujdsB-0006LI-E0 for 79124@debbugs.gnu.org; Wed, 06 Aug 2025 09:08:04 -0400 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 1ujds4-0007xO-76; Wed, 06 Aug 2025 09:07:56 -0400 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=/uPW98bdixnBsiHkJd0HK29EioOLnS66vcKRDblaWB4=; b=PnocpBRT7dGJ BMojRnhsY/+z1mADSZ4kUZqkZbmUH9b2aQN5LIh7UfcWYs625bAKPlpW6SnPqkYa5rRu7J1jXy6n7 F3hNr2zXqpdeW/CttC5/6UIKS4uxXPDAj2OJ7AuCok8VOxwoHBvlstiksA2Zk1I8euCz3lI2T9Mso 9SoiWPq4Bth/x5jr9daurIpLVF1c6RLU++IfTSQkIvLiICTRXgnayKkkOykdRdoGOpEP5iYNV0z+K vsREiBbR3MyLaWJyhHzVIISu1aRFQ+GEZT9WO6az3Dgsf/O2Tdy3IdUcqUDgLKE3p0ZofudIyiwxA Eeaz+Yo9iaUs0xnIfVcJrA==; Date: Wed, 06 Aug 2025 16:07:45 +0300 Message-Id: <868qjwtx7i.fsf@gnu.org> From: Eli Zaretskii To: Manuel Giraud In-Reply-To: <875xf08zuc.fsf@ledu-giraud.fr> (message from Manuel Giraud on Wed, 06 Aug 2025 13:16:27 +0200) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <87a54d8xlp.fsf@ledu-giraud.fr> <875xf08zuc.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, eggert@cs.ucla.edu, 79124@debbugs.gnu.org, rms@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 (---) > From: Manuel Giraud > Cc: Eli Zaretskii , rpluim@gmail.com, 79124@debbugs.gnu.org, > rms@gnu.org > Date: Wed, 06 Aug 2025 13:16:27 +0200 > > Paul Eggert writes: > > > Although these are not fatal objections, they're messes that we're > > better off without. Testing should be simple, not complicated. > > Yes of course. The second part of my idea is that maybe -Q could be a > shortcut for "-q --no-site-file --no-splash > --init-directory=$TMPDIR_SOMEWHERE_THAT_WOULD_BE_DELETED_WHEN_QUITTING" That's an incompatible change, so we cannot easily make -Q do that. No one said that -Q makes the user's home directory inaccessible. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 06 09:49:55 2025 Received: (at 79124) by debbugs.gnu.org; 6 Aug 2025 13:49:55 +0000 Received: from localhost ([127.0.0.1]:58588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujeWg-0008Qb-Vm for submit@debbugs.gnu.org; Wed, 06 Aug 2025 09:49:55 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:58882) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujeWe-0008QJ-6D for 79124@debbugs.gnu.org; Wed, 06 Aug 2025 09:49:52 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id D53993C01086C; Wed, 6 Aug 2025 06:49:45 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id BVYgViVcoV3l; Wed, 6 Aug 2025 06:49:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id ABC0E3C010873; Wed, 6 Aug 2025 06:49:45 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu ABC0E3C010873 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754488185; bh=o83Rp+7xzMQBJcAjFpY/5wEvAUK8jasZsRqHjZrI2iM=; h=Message-ID:Date:MIME-Version:To:From; b=FjNaUSHNWYWx1Rtw52OOzXI7EefbNMr4y/ujjLJEQIn+MakCLz0LPYNClpyvrYzpP izdwOHHk//7QjvG5YLjK06RKiUXVreOdbpWc64FJev2GcrUnmuVdTAAhZtMDf96Iy4 8fxAnef/X6JBWIoH00ffJyx+a7myPIcRtBgVlwc/ixyGt3jTL/Q0VA+km+1gbWiUoH 3jQxEXB4VhQvc5Jt+wysAc2+5Y2TOFqS/lw89tphXha/tZfrMWOO68B/Ziz/ql1Rlf tOpsnAu/oxR0H7lhwhCnCxgt1WgzyB5oKfHkvHpi9jdoXAgyEpNHA84kSp6ewXl9gK mqPZfTxdUcfBA== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id Bt3U9s94Sjr2; Wed, 6 Aug 2025 06:49:45 -0700 (PDT) Received: from penguin.cs.ucla.edu (unknown [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 8053F3C01086C; Wed, 6 Aug 2025 06:49:45 -0700 (PDT) Message-ID: <7f328236-bc20-416e-a0e6-f401904f88c8@cs.ucla.edu> Date: Wed, 6 Aug 2025 06:49:45 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <86wm7htw32.fsf@gnu.org> <86h5yktyq7.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86h5yktyq7.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-08-06 05:34, Eli Zaretskii wrote: > The other part of the puzzle is that it is not always > possible to predict in advance what Lisp files will be automatically > loaded at startup because they are needed by the startup code, so they > couldn't all be natively-compiled in advance. That part of the puzzle does not apply, since -Q means "don't run startup code". > I'm not interested in adding yet another way of > avoiding native-compilation But I'm not asking for another way to avoid native compilation. Native compilation is fine. Just don't trust what's already in .emacs.d, that's all. > The solution we use in the test suite is to set HOME to a non-existent > directory, so that's what I can suggest in your case. That suggestion is inadequate, as it leads to bogus diagnostics and/or detritus after the test. However you are unwilling to change your mind even to add a simple flag, and you are a maintainer whereas I am not. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 06 09:51:07 2025 Received: (at 79124) by debbugs.gnu.org; 6 Aug 2025 13:51:07 +0000 Received: from localhost ([127.0.0.1]:58597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujeXq-00007I-JN for submit@debbugs.gnu.org; Wed, 06 Aug 2025 09:51:07 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:34066) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujeXl-00006c-H5 for 79124@debbugs.gnu.org; Wed, 06 Aug 2025 09:51:05 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id ACAEF3C01086C; Wed, 6 Aug 2025 06:50:55 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id Kp-4jC_60s9r; Wed, 6 Aug 2025 06:50:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 8661F3C010873; Wed, 6 Aug 2025 06:50:55 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 8661F3C010873 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754488255; bh=Jb2jGNc240g4IUyTvuyyJLhr2BZulxxUtm8WAOFVYK4=; h=Message-ID:Date:MIME-Version:To:From; b=gFZaVXvc37GFiUWNneJOjhrEIrHhlyb9K+LS1Btow7EtpLotCU//T0gLgRw7iRCEE qTOsB6AS5nm9ChJdg4lvqddODIAhtpxG8zMFmCnynoNYKkVpcTygh6If0dwzc3+bCf orUwlYMQ5bk13TdWmldfl1bbkHXPrPLsvf7GI8jFijCMvB33xTBnJD+Q0QEu7A5VJZ YJFqH2ExCzOm85R5YnFGafJ5+UsBAToUba6GwKu73fU/U0lf8DvW72rzIcU6SBpQws ywVf3tNr63S2QxGH4gtpeKN2KyzIkxABOilpMnQEevRG3J8GwcE4cVVJdsZ9Wfi921 eJ/1G6rPg/BUA== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id e47xWdmR77zX; Wed, 6 Aug 2025 06:50:55 -0700 (PDT) Received: from penguin.cs.ucla.edu (unknown [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 61A833C01086C; Wed, 6 Aug 2025 06:50:55 -0700 (PDT) Message-ID: <1b84ee3d-032d-4adc-acd5-6ce6b247d10e@cs.ucla.edu> Date: Wed, 6 Aug 2025 06:50:55 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Manuel Giraud References: <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <87a54d8xlp.fsf@ledu-giraud.fr> <875xf08zuc.fsf@ledu-giraud.fr> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <875xf08zuc.fsf@ledu-giraud.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: Eli Zaretskii , 79124@debbugs.gnu.org, rpluim@gmail.com, rms@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: -1.0 (-) On 2025-08-06 04:16, Manuel Giraud wrote: > Which directory does libgccjit create? /tmp/libgccjit-6kC11F in one test run. (Which belies the misguided notion that Emacs must do this stuff in its home directory.) > Yes of course. The second part of my idea is that maybe -Q could be a > shortcut for "-q --no-site-file --no-splash > --init-directory=$TMPDIR_SOMEWHERE_THAT_WOULD_BE_DELETED_WHEN_QUITTING" Eli already rejected a solution along those lines, unfortunately. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 06 10:56:12 2025 Received: (at 79124) by debbugs.gnu.org; 6 Aug 2025 14:56:12 +0000 Received: from localhost ([127.0.0.1]:59696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujfYm-0003X6-Ge for submit@debbugs.gnu.org; Wed, 06 Aug 2025 10:56:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50516) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujfYg-0003WY-G0 for 79124@debbugs.gnu.org; Wed, 06 Aug 2025 10:56:06 -0400 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 1ujfYZ-00045o-DW; Wed, 06 Aug 2025 10:55:55 -0400 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=sJUebbmnXOJHvO59FOn37Y7boAbTZGY/3wBqj1GceKQ=; b=HbDwFV/9MaAT 5QyFSPxdfUy++qnDzKTruH8GjN0KUfngoN6jnuAsFMHxtW4uFrZWZ1RtqdzKZHU5h42jrrKOeViay wAs2C9RgE40ES3LewtkQFIJ42jPYwgN0UZq87kU3W1oxNw+v3/+ERaCGKgQQQmydN5IFnynqAVr8z IVqAFPJiiIStiDTSdikYJgH95cuJA12HFoiyrb5mTl2RHinyM1S0TGnQfC1zJTWcGy3mMq/EcEPwV wD1jJPQBa5e3flqSjbA8iSxhrMY6XuB4rBhJv+W4kyB6Ipu5FhBhtIxia0ZDhHyW2RWlXfALhguXn 0rryk6y6vpf7PNVbFIcFtw==; Date: Wed, 06 Aug 2025 17:55:45 +0300 Message-Id: <86y0rwsdn2.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <7f328236-bc20-416e-a0e6-f401904f88c8@cs.ucla.edu> (message from Paul Eggert on Wed, 6 Aug 2025 06:49:45 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <88c41b89-5306-4a60-9244-03747a176e4e@cs.ucla.edu> <86o6t1ugu0.fsf@gnu.org> <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <86wm7htw32.fsf@gnu.org> <86h5yktyq7.fsf@gnu.org> <7f328236-bc20-416e-a0e6-f401904f88c8@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Wed, 6 Aug 2025 06:49:45 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-08-06 05:34, Eli Zaretskii wrote: > > > The other part of the puzzle is that it is not always > > possible to predict in advance what Lisp files will be automatically > > loaded at startup because they are needed by the startup code, so they > > couldn't all be natively-compiled in advance. > > That part of the puzzle does not apply, since -Q means "don't run > startup code". No, it doesn't. startup.el's code is run in "emacs -Q" as well (although some parts of it, like loading the user init file, are omitted). > > I'm not interested in adding yet another way of > > avoiding native-compilation > > But I'm not asking for another way to avoid native compilation. Native > compilation is fine. Just don't trust what's already in .emacs.d, that's > all. The way JIT native compilation works, it writes the *.eln files under the user home directory, and looks there for *.eln files that were already compiled. So yes, you are asking to either avoid this or significantly change how it works. > > The solution we use in the test suite is to set HOME to a non-existent > > directory, so that's what I can suggest in your case. > > That suggestion is inadequate, as it leads to bogus diagnostics and/or > detritus after the test. However you are unwilling to change your mind > even to add a simple flag, and you are a maintainer whereas I am not. My problem is not with adding a flag, it's with modifying code to support that flag. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 06 10:58:27 2025 Received: (at 79124) by debbugs.gnu.org; 6 Aug 2025 14:58:28 +0000 Received: from localhost ([127.0.0.1]:59706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujfb1-0003bZ-J4 for submit@debbugs.gnu.org; Wed, 06 Aug 2025 10:58:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58256) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujfaz-0003bF-5N for 79124@debbugs.gnu.org; Wed, 06 Aug 2025 10:58:25 -0400 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 1ujfas-0004H8-Sf; Wed, 06 Aug 2025 10:58:18 -0400 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=bS3AvtknAhLhJFb0GUJOmj184Pfqxl5n3n9mVXRB1H8=; b=UjOZHskiEj5X nDkg6cHe3v6hExjZway1Ev3n4lQyr0LRpSziBMLwWuRjOD1/NAlW44AkEJ0N6cXzS+zHdyf4UMnQ/ VUm0B+66t2Qh++omdI/6X2vnQhiKWG5y4pL5aJeFUIgeBY4EULJI4y1k01qUMu4ybSXNqBAccdxLQ lWc3n3E5JAlZu8Yp/Mozdmcm6b97iqTZSjxx1NWegL088e2Gn3AztVOAG9TqQ7WIT5HyvGUEzy6oP 8DInzSkPyrumdaf9SAbV2qnygudI4o5IQ59DyutnSDTpqhJdH/ZFXAXv2abcVXUDzWCjtZpZlYP5r aPqpVmx7zm/PgSJKBbw6pg==; Date: Wed, 06 Aug 2025 17:58:04 +0300 Message-Id: <86wm7gsdj7.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <1b84ee3d-032d-4adc-acd5-6ce6b247d10e@cs.ucla.edu> (message from Paul Eggert on Wed, 6 Aug 2025 06:50:55 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <87a54d8xlp.fsf@ledu-giraud.fr> <875xf08zuc.fsf@ledu-giraud.fr> <1b84ee3d-032d-4adc-acd5-6ce6b247d10e@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@gnu.org, manuel@ledu-giraud.fr 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 (---) > Date: Wed, 6 Aug 2025 06:50:55 -0700 > Cc: Eli Zaretskii , rpluim@gmail.com, 79124@debbugs.gnu.org, > rms@gnu.org > From: Paul Eggert > > On 2025-08-06 04:16, Manuel Giraud wrote: > > > Which directory does libgccjit create? > > /tmp/libgccjit-6kC11F in one test run. (Which belies the misguided > notion that Emacs must do this stuff in its home directory.) Are you sure this directory is created by Emacs, not by libgccjit itself? From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 06 11:37:52 2025 Received: (at 79124) by debbugs.gnu.org; 6 Aug 2025 15:37:52 +0000 Received: from localhost ([127.0.0.1]:59802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujgDA-0005Yr-98 for submit@debbugs.gnu.org; Wed, 06 Aug 2025 11:37:52 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:35134) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujgD8-0005YZ-0N for 79124@debbugs.gnu.org; Wed, 06 Aug 2025 11:37:50 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id ADFB23C0149C9; Wed, 6 Aug 2025 08:37:43 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id CshnZ4uK1P7w; Wed, 6 Aug 2025 08:37:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 838CF3C0149D0; Wed, 6 Aug 2025 08:37:43 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 838CF3C0149D0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754494663; bh=fVYeKIwWyslpvLCf3lPh8I6gNkSYxw77NRdtyDdkFQE=; h=Message-ID:Date:MIME-Version:To:From; b=ctLEHQ2+CBzSv/DfruVQLvfi8PNr4IIsRyuFz0lGuvGShD3OHI1E89m7riV9aIGna ahpaw4+IJVnQBHCgHB4ev7ZQua8kQRBXRDoDZqB8bMocmoDxOMwfMDev6jUf6Tp34b gOjvNAmwqPq+IriB/vefmLajZBT8jHlmHJa4iUfr/797KMHdE5tW78pY2icXhlCPSB gNyRpYIY+5MucwNQjxKxP8edjTf8TAwX6DhJ3B3sEw8gHu2bWvT1gShblCVXsWJzUP iVYyyqzdoj3vBW7YoXMzVdPKKLaOwr+Tc+f509dUpvoQcL2UiIBBmNdyyZHScAojag QqFxI3CMGXbYQ== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id sgakDZhp849E; Wed, 6 Aug 2025 08:37:43 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 5DD373C0149C9; Wed, 6 Aug 2025 08:37:43 -0700 (PDT) Message-ID: <6c7f2847-10ba-4249-add9-2bc44647685e@cs.ucla.edu> Date: Wed, 6 Aug 2025 08:37:42 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <86wm7htw32.fsf@gnu.org> <86h5yktyq7.fsf@gnu.org> <7f328236-bc20-416e-a0e6-f401904f88c8@cs.ucla.edu> <86y0rwsdn2.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86y0rwsdn2.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-08-06 07:55, Eli Zaretskii wrote: >>> The other part of the puzzle is that it is not always >>> possible to predict in advance what Lisp files will be automatically >>> loaded at startup because they are needed by the startup code, so they >>> couldn't all be natively-compiled in advance. >> >> That part of the puzzle does not apply, since -Q means "don't run >> startup code". > > No, it doesn't. startup.el's code is run in "emacs -Q" as well > (although some parts of it, like loading the user init file, are > omitted). I meant the user startup code. But I don't see why the other part of the puzzle applies for the non-user-specific part of startup.el, as that stuff ought to be precompiled, not taken from the user's home directory. >> But I'm not asking for another way to avoid native compilation. Native >> compilation is fine. Just don't trust what's already in .emacs.d, that's >> all. > > The way JIT native compilation works, it writes the *.eln files under > the user home directory, and looks there for *.eln files that were > already compiled. So yes, you are asking to either avoid this or > significantly change how it works. ? It's not much of a change to put in /tmp where it belongs. After all, Emacs puts this stuff in /tmp no matter what we do with $HOME, because libgccjit ignores $HOME and uses /tmp directly. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 06 12:22:48 2025 Received: (at 79124) by debbugs.gnu.org; 6 Aug 2025 16:22:48 +0000 Received: from localhost ([127.0.0.1]:59870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujgud-0007by-Us for submit@debbugs.gnu.org; Wed, 06 Aug 2025 12:22:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59088) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujgua-0007bj-Fp for 79124@debbugs.gnu.org; Wed, 06 Aug 2025 12:22:45 -0400 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 1ujguT-0007GD-J0; Wed, 06 Aug 2025 12:22:37 -0400 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=aQM+3UWTBzRsBAwUPqWD6uuaApdvLGXk3yQFx4LhvjA=; b=cYIaMa3gujBJ bDGe1s8RSHH3ivsCdyFCyx4Al6Mn8J6V2SjF4Nm+bIZjTBLaeqVH/XiSL8ExCqTOWSTupD2xA5coL LUbgDrLikpUEscPFr1sWBBjTgwlixffgW80v8xHjwHA6aL5Y7XAapDt8kA6rdbTSHDMTY4kHYZDhn AZ6ofsaZzf/V5dZbxO0tID0nmwfmVm/7VnIW8lvh32zR2jDeJiJCzStY2bTGTcHHCWGA9qLTXt5t0 miAfwXITjs3KCjZJq0QO61G8C7D7Uh5XBRmHwT0O5FnNfchaKcyohDA1eh/K2TGcTGUUkOFi8VJUS oMGIWMTAy9/nWGDfSI9R4A==; Date: Wed, 06 Aug 2025 19:22:26 +0300 Message-Id: <86ms8cs9ml.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <6c7f2847-10ba-4249-add9-2bc44647685e@cs.ucla.edu> (message from Paul Eggert on Wed, 6 Aug 2025 08:37:42 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <21817b70-97a6-495d-a0cf-892434134a8e@cs.ucla.edu> <86bjp0vrot.fsf@gnu.org> <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <86wm7htw32.fsf@gnu.org> <86h5yktyq7.fsf@gnu.org> <7f328236-bc20-416e-a0e6-f401904f88c8@cs.ucla.edu> <86y0rwsdn2.fsf@gnu.org> <6c7f2847-10ba-4249-add9-2bc44647685e@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Wed, 6 Aug 2025 08:37:42 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-08-06 07:55, Eli Zaretskii wrote: > >>> The other part of the puzzle is that it is not always > >>> possible to predict in advance what Lisp files will be automatically > >>> loaded at startup because they are needed by the startup code, so they > >>> couldn't all be natively-compiled in advance. > >> > >> That part of the puzzle does not apply, since -Q means "don't run > >> startup code". > > > > No, it doesn't. startup.el's code is run in "emacs -Q" as well > > (although some parts of it, like loading the user init file, are > > omitted). > > I meant the user startup code. But I don't see why the other part of the > puzzle applies for the non-user-specific part of startup.el, as that > stuff ought to be precompiled, not taken from the user's home directory. Because startup.el can load Lisp packages that are not preloaded. The terminal-specific library from lisp/term/ and warnings.el are two that come to mind, but I won't be surprised that there are more. > >> But I'm not asking for another way to avoid native compilation. Native > >> compilation is fine. Just don't trust what's already in .emacs.d, that's > >> all. > > > > The way JIT native compilation works, it writes the *.eln files under > > the user home directory, and looks there for *.eln files that were > > already compiled. So yes, you are asking to either avoid this or > > significantly change how it works. > > ? It's not much of a change to put in /tmp where it belongs. After all, > Emacs puts this stuff in /tmp no matter what we do with $HOME, because > libgccjit ignores $HOME and uses /tmp directly. I fail to see the difference between trusting files in /tmp and trusting files in ~/.emacs.d/eln-cache. It sounds to me like some dogmatic notion which has no real basis. Why should we make changes in what is already super-complicated code on such shaky grounds? No, thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 06 12:29:52 2025 Received: (at 79124) by debbugs.gnu.org; 6 Aug 2025 16:29:52 +0000 Received: from localhost ([127.0.0.1]:59878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujh1U-0007s9-DE for submit@debbugs.gnu.org; Wed, 06 Aug 2025 12:29:52 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:54130) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujh1S-0007rv-Ja for 79124@debbugs.gnu.org; Wed, 06 Aug 2025 12:29:51 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id B10F43C01084A; Wed, 6 Aug 2025 09:29:44 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id hw8KwbchnCPA; Wed, 6 Aug 2025 09:29:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 8899D3C0149C9; Wed, 6 Aug 2025 09:29:44 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 8899D3C0149C9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754497784; bh=WH9keG/jlyp8puNz+DCU1CG8TDKspLbSOhbhdn8xlZM=; h=Message-ID:Date:MIME-Version:To:From; b=RhUcxWYyQDwHTWdDeG7J2mPPGNyjNRFdIdsu3dfXNkyX55OYp6DWxwTNinMsy22ZE SDN6USe3+v5e/YZH/YbTxpN0yq4kYk5rx4ArsVG57DT0OCgrBdz36+q/ayFDZMp7h/ kjUsBJqwetwCEUdwpdHIh950kKxg2k0dX8SZnmLUdnlscUSpqr4ISeb8VnvUqJyoEo U0XGfRv5Xbd8bGDdI/4bkoC9OT6G5OlNT2nayE6Xx0Sr22trpXF9LeOX7/KPOOIfDB q7KDcDYhuewdsz3JlgALBVLPXVId9ETg7X3+0Z+OHHLRX8OSIYFd5dIKuZvMXnDxAs lS9zAFEzXeh9g== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id d74weG0h2lUb; Wed, 6 Aug 2025 09:29:44 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 608DD3C01084A; Wed, 6 Aug 2025 09:29:44 -0700 (PDT) Message-ID: <1c3a009a-7f00-4464-a335-78361b12a4db@cs.ucla.edu> Date: Wed, 6 Aug 2025 09:29:44 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <86wm7htw32.fsf@gnu.org> <86h5yktyq7.fsf@gnu.org> <7f328236-bc20-416e-a0e6-f401904f88c8@cs.ucla.edu> <86y0rwsdn2.fsf@gnu.org> <6c7f2847-10ba-4249-add9-2bc44647685e@cs.ucla.edu> <86ms8cs9ml.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86ms8cs9ml.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-08-06 09:22, Eli Zaretskii wrote: > Because startup.el can load Lisp packages that are not preloaded. The > terminal-specific library from lisp/term/ and warnings.el are two that > come to mind, but I won't be surprised that there are more. That's fine; these files can be compiled as needed. Emacs simply need not consult the user home directory to see whether they have already been compiled by a previous Emacs execution. > I fail to see the difference between trusting files in /tmp and > trusting files in ~/.emacs.d/eln-cache. Those files in /tmp are all created by the current Emacs execution, and can be trusted for that reason. The files that were already in ~/.emacs.d/eln-cache are not, and they might have been corrupted for various reasons since they were created by a previous execution. That's an important difference. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 06 15:00:11 2025 Received: (at 79124) by debbugs.gnu.org; 6 Aug 2025 19:00:11 +0000 Received: from localhost ([127.0.0.1]:60225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujjMx-0006Hz-63 for submit@debbugs.gnu.org; Wed, 06 Aug 2025 15:00:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44868) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujjMu-0006GV-Mk for 79124@debbugs.gnu.org; Wed, 06 Aug 2025 15:00:09 -0400 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 1ujjMo-000410-Hd; Wed, 06 Aug 2025 15:00:02 -0400 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=Y5I/womqTf6J6gVYaXHqcwL2MNd17FRf1TUUmP8BRVQ=; b=HuKUBlQ3XVIm zmuguxnB1ohIvENep4EJryT94iETW6bS0fI2aeQwJNwRZezOOmi/EgAe3TBXUYuX/xE0EPYWQeJRA ZRyLF/E2yd02ep6+pg1oXPmyeX60Pwhk1ZqcOsbSv7KMB89RekUR4vHwbKMV9QpFegQtDAPsPgmHP qFN04CKL7aQ2ljqEvvHzS4odqdDFT+ZE2UlqAhTOFuAd2IL7BZ8fdLmKF4eIBo2IClDUyNbQ/PFbw IX7zeN0yJcrXOBFWzK/0Ahf4QhrxGomGRPCKaryYial6nzD+GIJpqihxTKlZvI60Q2TPzY5h6rTcu S7iDtYMBg1P38yie7ptJ7Q==; Date: Wed, 06 Aug 2025 21:59:49 +0300 Message-Id: <86jz3gs2ca.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <1c3a009a-7f00-4464-a335-78361b12a4db@cs.ucla.edu> (message from Paul Eggert on Wed, 6 Aug 2025 09:29:44 -0700) Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate References: <864iusuzkq.fsf@gnu.org> <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <86wm7htw32.fsf@gnu.org> <86h5yktyq7.fsf@gnu.org> <7f328236-bc20-416e-a0e6-f401904f88c8@cs.ucla.edu> <86y0rwsdn2.fsf@gnu.org> <6c7f2847-10ba-4249-add9-2bc44647685e@cs.ucla.edu> <86ms8cs9ml.fsf@gnu.org> <1c3a009a-7f00-4464-a335-78361b12a4db@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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 (---) > Date: Wed, 6 Aug 2025 09:29:44 -0700 > Cc: rpluim@gmail.com, rms@gnu.org, 79124@debbugs.gnu.org > From: Paul Eggert > > On 2025-08-06 09:22, Eli Zaretskii wrote: > > > Because startup.el can load Lisp packages that are not preloaded. The > > terminal-specific library from lisp/term/ and warnings.el are two that > > come to mind, but I won't be surprised that there are more. > > That's fine; these files can be compiled as needed. Emacs simply need > not consult the user home directory to see whether they have already > been compiled by a previous Emacs execution. It currently can't, and I'm unwilling to complicate what we have so it will be able to, sorry. > > I fail to see the difference between trusting files in /tmp and > > trusting files in ~/.emacs.d/eln-cache. > > Those files in /tmp are all created by the current Emacs execution, and > can be trusted for that reason. The files that were already in > ~/.emacs.d/eln-cache are not, and they might have been corrupted for > various reasons since they were created by a previous execution. That's > an important difference. I fail to see the important difference: who said the corruption, such as it is, could only happen some time ago, but not immediately as the files are created? But this discussion leads nowhere, since we both have opinions that cannot be changed by these arguments. So let's leave it at that. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 06 15:26:14 2025 Received: (at 79124) by debbugs.gnu.org; 6 Aug 2025 19:26:14 +0000 Received: from localhost ([127.0.0.1]:60279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujjm9-0007au-On for submit@debbugs.gnu.org; Wed, 06 Aug 2025 15:26:14 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:59278) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujjm5-0007aO-N4 for 79124@debbugs.gnu.org; Wed, 06 Aug 2025 15:26:12 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 8927E3C0149C9; Wed, 6 Aug 2025 12:26:03 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id SQbJnwX0iFD5; Wed, 6 Aug 2025 12:26:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 60B9B3C0149E2; Wed, 6 Aug 2025 12:26:03 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 60B9B3C0149E2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1754508363; bh=fwhFBysUiXDt/xHT80j6aEHv4ZObHzefLIbevUzw37w=; h=Message-ID:Date:MIME-Version:To:From; b=PuHSkQ+1Y1xKH0Ol255eHj23v/0en2qDROkqKXVlEaQKMfhSIPxAAcOHTuAZaLIxG bOCeEwaAXBRCuSQSn4BZwQoESWYk7uAiTtBFPTpSVhdJaU/xEm4uhgngK561EHEGfA yM87BoTLKsS9htXRqB7Sj90fUftXzowMHQvVIkOwfe+nUmPcxAHWKtwHnKGkxlzIuq h+5nDdHrObfYNyusPbDwPK5OloZrmK7DBgXIjnbwZfcCgaCv1h4zpCQjV9j5xqBYAK 8KJ/MQISuuZixbK0UBJV2dDGoDzGYVb9toLmIj06iSZW60A4Men31euAiKgETimlzM gdZQ1O3SnawBA== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id rt6tXwAtiqxc; Wed, 6 Aug 2025 12:26:03 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 360C33C0149C9; Wed, 6 Aug 2025 12:26:03 -0700 (PDT) Message-ID: <913b41b5-e43a-4ca9-a875-33e727e88284@cs.ucla.edu> Date: Wed, 6 Aug 2025 12:26:02 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate To: Eli Zaretskii References: <861ppvvb6w.fsf@gnu.org> <3fe1ed06-5bf4-4879-b9b5-24e20f1bc411@cs.ucla.edu> <86zfchplos.fsf@gnu.org> <90219bb5-068a-4561-86fb-4175734e7ff7@cs.ucla.edu> <864iuoxu7x.fsf@gnu.org> <86o6svwa1s.fsf@gnu.org> <861pprvtsf.fsf@gnu.org> <86qzxquic2.fsf@gnu.org> <217fa069-7886-4297-8620-141968704846@cs.ucla.edu> <8634a5vk4o.fsf@gnu.org> <8383405f-7e28-4e03-9237-0bde17f4204d@cs.ucla.edu> <86wm7htw32.fsf@gnu.org> <86h5yktyq7.fsf@gnu.org> <7f328236-bc20-416e-a0e6-f401904f88c8@cs.ucla.edu> <86y0rwsdn2.fsf@gnu.org> <6c7f2847-10ba-4249-add9-2bc44647685e@cs.ucla.edu> <86ms8cs9ml.fsf@gnu.org> <1c3a009a-7f00-4464-a335-78361b12a4db@cs.ucla.edu> <86jz3gs2ca.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86jz3gs2ca.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79124 Cc: rpluim@gmail.com, 79124@debbugs.gnu.org, rms@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: -1.0 (-) On 2025-08-06 11:59, Eli Zaretskii wrote: > I fail to see the important difference: who said the corruption, such > as it is, could only happen some time ago, but not immediately as the > files are created? It's of course theoretically possible, just as many other things are theoretically possible. But practically speaking, it's far, far more likely for a user to screw up their home directory over a period of several hours or days or more, using any of many common techniques (e.g., backups or restores going wrong). None of that is at all likely with /tmp files created a few milliseconds ago. This is a practical issue, not a theoretical one. It's better to not ignore practical issues merely because of concerns about issues that are problems only in theory. However, as I mentioned you are a maintainer and I am not, and I suppose Emacs users will have to live with your opinion, right or wrong.