Talk:XDG Base Directory support

From ArchWiki
Jump to: navigation, search


Has anyone looked at XDG Directories for emacs? Ben Creasy (talk) 02:40, 15 July 2015 (UTC)

It seems that still needs an ~/.emacs, so I'm unsure it's a great improvement over a single ~/.emacs.d. That said, you could try to start emacs with the --load or --directory argument. -- Alad (talk) 09:15, 1 September 2015 (UTC)


I've just revised the VCS management of my config files and had to put configs of practically all graphical programs to .gitignore, because they all abuse the $XDG_CONFIG_HOME path for the purpose of persistent cache, which is $XDG_CACHE_HOME. A typical config file of a Qt programs looks like this, notice especially the recentFileList, geometry and windowState keys -- IMHO this is exactly the stuff that belongs to $XDG_CACHE_HOME or $XDG_DATA_HOME. The Qt programs are notorious, I suspect the toolkit itself is responsible. But there is more: inkscape puts there extension-errors.log, syncthing even the entire database. What shall we do about this? There are not many graphical programs in the tables on this page, but inkscape is listed under "Supported", which is not entirely true... -- Lahwaacz (talk) 22:12, 21 August 2015 (UTC)

The article uses "workarounds [that] will be limited to anything not involving patching the source, executing code stored in environment variables or compile-time options." as an arbiter for the "Partial" category, and anything more complicated than that for "Hardcoded". I.e., categorization is based on what's needed to moving dotfiles from $HOME to some, hopefully correct, XDG directory or directories.
One way to supplement this would be the Notes column in the Supported category (which is now mostly empty anyway), to expand on programs which don't follow the intent of the XDG directories or which just lazily stack things together. -- Alad (talk) 09:08, 1 September 2015 (UTC)
This is why adding * to GIT_DIR/info/exclude is so great. I have no idea why people who are familiar with git don't do this by default. This allows you to only track files you explicitly want to track with impunity. But yes, there's plenty of programs which don't follow the spec to the letter and that's mostly fine; it's fine because at least the root of their directory is now under user control. Using git properly makes this a non-issue and I'd rather projects at least support some of XDG than be forever debating what "cache" vs "data" means... Earnest (talk) 15:31, 12 September 2015 (UTC)

Arch package page, or project page?

Currently in the Application column of the tables, there are three types of links: wiki links like fish, package links like ncurses (including AUR like sublime-text-devAUR), and project links like antimicro. Is there any consensus about the preference of these three types? I suggest wiki links over package over project links, because:

  1. Wiki pages have more information, and typically contains both package links and project links.
  2. Package pages contains project links, along with some information useful to Arch users.

Thoughts? --Franklin Yu (talk) 20:28, 22 April 2017 (UTC)

To be honest I'm not sure why this page even contains package links; we have List of applications and dedicated articles where we already keep those links up-to-date. Using wiki links instead does sound like a better idea. -- Alad (talk) 22:47, 22 April 2017 (UTC)
So you prefer project links over package links? Or no link at all, if the application does not have a Wiki link? --Franklin Yu (talk) 06:22, 23 April 2017 (UTC)

Should command-line history be data or cache?

Should they be placed in XDG_DATA_HOME, or XDG_CACHE_HOME? --Franklin Yu (talk) 20:07, 16 May 2017 (UTC)

Cache is data than can be deleted at any time without losing anything important, as it can be regenerated by the application (e.g. by re-downloading something or otherwise). Data in XDG_DATA_HOME on the other hand has an impact on what the user can do, and the user would mind about losing it. Of course it may depend on the application in question where you draw the line of what's "important", but when deleting command line history, (1) the user loses possibilities (reusing a command) and information/knowlege ("what was that command again?"), and (2) the data cannot be regenerated by the application, so I would clearly put it in XDG_DATA_HOME. —Ayekat (talk) 22:30, 16 May 2017 (UTC)

nvidia uses XDG_CACHE_HOME, how to test CUDA?

Using nvidia 390.25 and just noticed that it now stores its cache in $XDG_CACHE_HOME/.nv rather than ~/.nv and edited the page accordingly. I don't know if CUDA was also changed and don't know how to check. If someone else knows, please tell me or try it yourself and update the page if needed. I already checked nvidia-settings, it is not yet changed.

Cyant (talk) 11:55, 25 February 2018 (UTC)