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

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 9 Nov 2021 12:38:52 -0800
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> 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"

I'm saying that user-directory should also honor user-emacs-directory,
because we have no way of knowing the intent of the caller of
user-directory: it could be that the caller wants then to get to some
file under it.

> 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.

Could be, indeed.  (But please make user-file accept nil instead of an
empty string.)

> >>   ./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.

That's a bummer, because we didn't intend to preload xdg.el.  And
since it prefers the "traditional" setups anyway, I wonder whether
preloading it would be justified, as in most cases its code will be
trivially bypassed.

> >   $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.

That's not true for the *.eln files: they cannot be "simply lost".
Note that the XDG spec says "data files", which *.eln aren't: they are
code.  I think it would be wrong to put *.eln files there for the same
reasons it would be wrong to put *.elc files there.

> > 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'.

Why not start with (2)?  It will save us one step.

> 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")

If the 2nd argument is optional for alternative names, that's OK, I
think.

Thanks.