no-littering and emacs -Q

[yantar92]

I often need to run Emacs without my configuration, just via emacs -Q.

emacs -Q annoyingly creates a number of folders in .emacs.d. Most often, auto-save..., backup, and tramp. And eln-cache.

It would be nice to prevent this somehow.

[tarsius]

Yeah, this has been (lightly) bothering me for a long time as well. What are you proposing we do about it?

That I add a no-littering-Q.el?
But why not just use no-littering.el-proper in that case as well?

alias emacsq="emacs -Q -L ~/.config/emacs/lib/no-littering -L ~/.config/emacs/lib/compat -l no-littering"

[yantar92]

Jonas Bernoulli ***@***.***> writes:

Yeah, this has been (lightly) bothering me for a long time as well. What are you proposing instead? That I add a `no-littering-Q.el`? But why not just use `no-littering.el`-proper in that case as well? ``` alias emacsq="emacs -Q -L ~/.config/emacs/lib/no-littering -L ~/.config/emacs/lib/compat -l no-littering" ```

That will not work when I have no control over how emacs is started (like when using Makefile). Of course, I can still configure bash and every project to use the alternative emacs command, but that's no less awkward than having spurious files. One possibility might be installing "site-file" - it will not be loaded with emacs -Q, but at least it will be loaded with emacs -q. A more reliable option would be contributing to Emacs upstream. May it be that writing into .emacs.d from emacs -Q can be considered a bug?

…

-- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>

[tarsius]

That will not work when I have no control over how emacs is started

I have mostly given up on this as a result and just periodically clean out these directories when I notice them.

(Preventing spurious eln-cache directories seems particularly hard, due to large changes in how that is done across emacs versions, and some of these iterations appearing to be buggy.)

A more reliable option would be contributing to Emacs upstream.

I see no-littering as a kind of band-aid until Emacs handles "this", and don't think that adding it more or less as-is to Emacs would be the right way. But I agree, this shouldn't require a package that isn't part of Emacs itself.

locate-user-emacs-file was a step in the right direction but unfortunately didn't take it far enough.

Vaguely, this function should take an additional argument TYPE, with values data and config (and possibly some more) and it should be configurable. Some users might want to do exactly what no-littering does, while others might want to use the etc subdirectory but use ~/.cache/emacs/ for data files. Some might want to use per-package subsubdirectories. Others might want to place all files, data and config, in a single directory, but make that a subdirectory of ~/.config/emacs, or not. Some users might want to use per-package directories, each with a config and a data subdirectory. And many more combinations.

Something along these lines. Or in other words, package maintainers should be encouraged to use locate-user-emacs-file to specify what kind of file exactly it is dealing with; and users can then use that information to control where the file should be placed, and maybe how it is named, based on that information. The TYPE argument would be a start, but other arguments might also be useful, e.g., DIRECTORYP.

[tarsius]

Arguments PACKAGE and PARENT-PACKAGE would also be useful. The value of the latter could be helm for a helm-foobar package, for example. Users could then decide whether to place the files of the "extension" in the package's own directory or in that of the "main" package.

[tarsius]

Of course that would mean that the extended locate-user-emacs-file would have to be added to the compat package and it would take many years until "most" packages would be updated to use that function and its new arguments.

[yantar92]

Jonas Bernoulli ***@***.***> writes:

> A more reliable option would be contributing to Emacs upstream. I see `no-littering` as a kind of band-aid until Emacs handles "this", and don't think that adding it more or less as-is to Emacs would be the right way. But I agree, this shouldn't require a package that isn't part of Emacs itself. `locate-user-emacs-file` was a step in the right direction but unfortunately didn't take it far enough. ...

Hmm. I did not mean to implement customized directory structure in the core. (It is indeed a nice goal, but certainly not easy to do) What I had in mind is that emacs -Q should not touch .emacs.d at all, like it refuses to save customized variables. Instead, `locate-user-emacs-file' should point to a throwaway folder when emacs is started with -Q command line option.

…

-- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>

[meedstrom]

@yantar92 you could also always use --init-directory=~/my-custom-emacsd to start your "main" Emacs. Then whatever goes on in ~/.emacs.d would not need to concern you.

But I agree that -Q should create a new throwaway folder. Makes a lot of sense.