emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: user-directory: New library to find user {conf, data, state, ...} fi


From: Stefan Kangas
Subject: Re: user-directory: New library to find user {conf, data, state, ...} files
Date: Tue, 9 Nov 2021 12:38:52 -0800

Eli Zaretskii <eliz@gnu.org> writes:

>> When looking for the directory, the new one will always be preferred.
>> The old name in all cases is just `user-emacs-directory', so it doesn't
>> make sense to look for it.
>
> That's not true, unless we are mis-communicating.  I have quite a few
> directories under ~/.emacs.d/, and most of them are important.  Are
> you saying we will now look for them all according to the XDG spec?

Aha, yes we are talking about two different things.

If you need some file in `user-emacs-directory' ("file" in the Unix
sense here, i.e. it could also be a directory) you would use
`user-file'.  So to get "~/.emacs.d/auto-save-list/" you would say:

    (user-file 'state "auto-save-list")
    => "~/.local/state/emacs/auto-save-list"

`user-directory' only returns the top-level directory.  There is no way
to give it a name of a file.

    (user-directory 'state)
    => "/home/skangas/.local/state/emacs"

However, your question makes me think that we should make `user-file'
the only public function here, to avoid confusion.  I think it's rare to
need the directory itself, and if someone does they could just use

    user-emacs-directory
    => "~/.emacs.d/"

or

    (user-file 'cache "")
    => "~/.cache/emacs"

So I think we should rename the library to user-file.el, and make
`user-file' the only non-internal and user-facing function.  That makes
it simpler, and more clear.

>>   ./startup.el547:      (push (expand-file-name "eln-cache/"
>> user-emacs-directory)
>
> Isn't that a problem?  It would mean we'd need to preload xdg.el and
> user-file, and all the stuff they need to work, right?  Also, the XDG
> spec says about "cache":

Yes, if we want to move the eln-cache to the cache directory, we need to
do something about preloading.  The relevant XDG code could be moved
from xdg.el and xdg.el could depend on the preloaded location; this is
about 30-40 lines of code.  We would also need to rewrite the code I
have in user-directory.el to not use cl-lib.el.

>   $XDG_CACHE_HOME defines the base directory relative to which
>   user-specific non-essential data files should be stored.
>
> I don't think files in eln-cache can be classified as "non-essential".
> They are important for using Emacs; removing them will make Emacs slow
> and sluggish for quite some time after startup.

Removing anything from a cache will always make performance worse until
you can recache it, but the character of a cache is that it can always
be recreated from some original data.

So my understanding is that "non-essential" here is provided to contrast
with the data file, and simply means that it is not (highly) important
not to lose those files.  I.e. it is just a way to further specify that
this is the directory for cached files.

> And you are saying we will redirect all those to the XDG tree?  Users
> have files in these places, and they need to trust Emacs to find those
> files when it is restarted.  How can we change where we look for them
> without breaking configurations?

For each file NAME: (1) look for NAME in the XDG directory, if NAME
exists there and is readable return it, otherwise (2) look for it in
`user-emacs-directory', if NAME exists there and is readable return it,
otherwise (3) return the file name of NAME in the XDG directory.  This
is the same basic approach that we also use in `locate-user-emacs-file'.

Is that what you mean?

>>     (user-file 'data "bookmarks" "~/.emacs.bmk")
>
> Once again, why not just one argument?

For backwards compatibility.  The "bookmarks" file used to be in
"~/.emacs.bmk" (before 2010 or so?).

We currently locate it using this call:

    (locate-user-emacs-file "bookmarks" ".emacs.bmk")



reply via email to

[Prev in Thread] Current Thread [Next in Thread]