Re: Texinfo 7.0 changed the name of HTML output directory

[Eli Zaretskii]

> Date: Mon, 26 Aug 2024 19:53:43 +0200
> From: Patrice Dumas <pertusus@free.fr>
> Cc: GavinSmith0123@gmail.com, bug-texinfo@gnu.org
> 
> > XDG is supported only on some systems.  For example, MS-Windows
> > doesn't support it, and I'm not sure about macOS.
> 
> I have not seen anything platform specific in the specification, as far
> as I can tell (except for the path separator), no more than what we
> currently do.

The directories that are the default values of the various XDG
locations do not necessarily exist (or even make sense) on other
systems.  And system utilities and services do not recognize them, so,
for example, the cache directory is not cleaned up from time to time.

> > So my suggestion is look for the files in their traditional places,
> > and failing that to fall back on XDG-mandated locations (with suitable
> > defaults as defined by XDG, if the relevant environment variables are
> > not set).
> 
> But that means that you support forever two locations, the traditional
> places, and the XDG-mandated locations if variables are not set.  I
> wanted to support only one, the XDG-mandated locations if variables are
> not set and deprecate the traditional locations (and use the XDG
> environment variables if set, but there is no trade-off with that case).

I understand the desire, but I don't think it's practical to make such
abrupt changes in user-facing facilities.

Again, it's just my opinion and my experience.

> > This is what Emacs does, and we have yet to hear a single
> > complaint.  We found this to be the best alternative in terms of
> > backward compatibility: it allows users smooth migration to
> > XDG-compliant configuration if and when they so desire.
> 
> It's no wonder that no one complain, all the added complexity is on you. 

Not entirely true, because the users need to understand this logic and
what it does when the XDG directories do exist.  For example, when
Emacs is started and the user init file does not yet exist, and some
Emacs command creates the init file, users need to understand where
will that file be created.

But yes, most of the burden related to this complication is on the
Emacs developers, not on users.