Subject: bug#79124: emacs -Q doesn't give me a clean slate

From: Manuel Giraud <[email-masked]>
Date: Tue, 05 Aug 2025 19:52:34 +0200

Paul Eggert <[email-masked]> 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