Re: master f8fed41 2/3: image-dired: Improve XDG compliance

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 26 Oct 2021 16:45:04 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I proposed to have a couple of higher-level APIs that will hide
> > system-dependent stuff, including hard-coded strings if some systems
> > need that.  xdg.el will then be one layer lower, and application code
> > will not call it directly.
> 
> OK, I think we agree that this would be a good thing.
> 
> The contentious point seems to be what we should do until we have such
> a library.  I think that it is better to update hardcoded strings to
> use xdg.el, since it will make the above idea easier to implement.
> 
> However, if we have a plan for a higher-level API in a reasonable
> time-frame (for example, before Emacs 29 is released), then I am more
> than happy to accept that we might as well wait with any such changes
> until that work is done.

It is so easy to provide this API (or set of APIs) piecemeal that I
don't see why we would need to wait for anything.  Let's simply start
a file called, say, std-dirs.el or somesuch, and add support there for
each directory we bump into.  For example, in the specific case that
triggered this, just add a function there that calls

  (or (xdg-user-dir "PICTURES") "~/pics/")

and call that function in image-dired.el.  Before long, we will have
everything we need, and more.  If you don't want to provide support
for anything except XDG, you can initially leave the fixed strings
there as the alternatives, and someone else will pick up where you
left off and fill in the blanks.

The only decision we need to make is whether we want a single function
that accepts an argument telling it the purpose of the standard
directory (in this case, I'd use 'PICTURES, a symbol), or maybe a
separate function for each kind of directory, like user-pictures-dir.