On Mon, Aug 26, 2024 at 02:29:10PM +0300, Eli Zaretskii wrote: > > Date: Mon, 26 Aug 2024 09:02:37 +0200 > > From: Patrice Dumas <[email protected]> > > > > On Sun, Aug 25, 2024 at 06:57:42PM +0100, Gavin Smith wrote: > > > On Sun, Aug 25, 2024 at 02:15:17PM +0200, Patrice Dumas wrote: > > > > On Sun, Aug 25, 2024 at 11:32:01AM +0100, Gavin Smith wrote: > > > > > We should at least support the "XDG Base Directory Specification". > > > > I see three possibilities for the locations that do not already follow > > the XDG Specification, locations like /etc/texinfo or /etc/texi2any, and > > locations like $HOME/.texinfo or $HOME/.texi2any > > > > 1) remove them as possibilities completly and mark in the documentation > > that the new directory have to be used > > 2) keep them as possibilities but mark them deprecated in the > > documentation, add warnings in the code and keep them about 5 years > > 3) keep them and maintain them > > > > I would lean towards 2), otherwise there would be too many directories > > searched for. > > > > Opinions? > > 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. > 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). > 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. I wanted to avoid that. > (Btw, AFAIK XDG directories can be ephemeral, and the environment > variables can be removed when the user logs off. This should be kept > in mind when designing the support for XDG.) Ok. -- Pat
