[Top][All Lists]

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

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

From: Stefan Kangas
Subject: Re: master f8fed41 2/3: image-dired: Improve XDG compliance
Date: Tue, 26 Oct 2021 16:01:50 +0200

Eli Zaretskii <eliz@gnu.org> writes:

> XDG is also prone to fashion changes.  What will we do when it goes
> out of fashion, and we have dozens of xdg-user-dir calls in our
> application code? change all of them to some latest desktop fashion?

Yes, that's what we should do in that case.  Such work will be much
easier if we have already adapted our code to use the xdg
specification: if you move xdg.el to "lisp/obsolete" the byte-compiler
will warn about any places where we use it.  But we have no easy way
to find strings like "~/pics", and therefore can't easily update them.

In other words, if we expect the standard to change very soon, it is
already a step forward to update hardcoded strings like "~/pics" like
I did in image-dired.el.

However, I don't really see any reason to expect a replacement to the
XDG Base Directory Specification (XDG BDS) any time soon.  As Philip
points out, it has only become more ubiquitous over the almost 20
years since its inception, and no replacement is on the horizon.
Therefore, this all seems very academic to me, and I think the points
below about other platforms are more immediately relevant.

> Can we agree not to use xdg.el in application code, and instead
> develop those abstractions and start using them?  For example, how
> about having a function user-pics-directory, which will return the
> appropriate file name for the underlying platform?  Doing that will
> not diminish our support for XDG (as long as it lasts), but will allow
> us to have application code XDG-clean, so to speak.

I have no objections to the general plan you propose, and I encourage
anyone with a particular interest in such support to work on it.  (It
will be mainly of interest to macOS or MS-Windows users, I think?  But
they should probably already be using a lot of software that uses the
XDG BDS.  I note that I have several BDS mandated directories on my
macOS laptop.)

However, I do not see any logic in stopping work on XDG BDS support
until such a library or functions has been implemented.  Just like
above, any work we do in conforming better to the XDG BDS can only
serve to make the "platform independent" or "XDG BDS independent" plan
you propose easier to implement.

reply via email to

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