Vim Lands XDG Base Directory Specification Support

[phoronix]

Phoronix: Vim Lands XDG Base Directory Specification Support

For fans of the Vim text editor, the latest development code has landed support for the XDG Base Directory "XDG_BASE_DIR" specification...

https://www.phoronix.com/news/Vim-XDG-Base-Directory-Spec

[mxan]

Didn’t take long after its creator’s death to start going downhill!

[hsci]

XDG-Speccification is fine. Especially it allows to delete or rename the directories, which I usually do:

https://wiki.archlinux.org/title/XDG_user_directories

Run xdg-user-dirs-update after modification. I delete the directories I don't use (e.g. "Desktop" which is of no use with GNOME) and rename all others to lowercase characters only. The later is just just for convenience (visual) and follow the convention (e.g. sorting) on Linux.

Aside from that I will stick with ~/.vimrc which is simple to access and doesn't apply indirection. It is easier to "reset" an application by deleting all `~/.foo` than searching {XDG_CONFIG_HOME, XDG_CACHE_HOME, XDG_DATA_HOME, XDG_STATE_HOME, XDG_RUNTIME_DIR}. Yes, this follows the convention of Linux. But maybe for that case {~/.foo/, ~/foo/config, ~/.foo/cache, ~/foo/state} would've been a better choice?

[kpedersen]

Didn’t take long after its creator’s death to start going downhill!

Indeed. I thought NeoVim was developed in order to protect us from people who wanted to break Vim.

To be fair, it started getting a bit sloppy when they added a :terminal emulator into it. I am just glad that I got a decent workflow going with (n)vi+tmux half a decade ago.

[hsci]

Didn’t take long after its creator’s death to start going downhill!

I would be a more sensitive and careful which such a comment.
It seems just an option, not a breaking change or removed feature.

[ssokolow]

Yes, this follows the convention of Linux. But maybe for that case {~/.foo/, ~/foo/config, ~/.foo/cache, ~/foo/state} would've been a better choice?

The intent behind it was that...

• You can just exclude ~/.cache/ from your nightly backups and a space-freeing tool doesn't have to have special knowledge of each application to clean it
• ~/.local/share was supposed to be userdata which should roam and must not be lost, akin to Microsoft's roaming AppData folder.
• If I remember correctly, ~/.local/state was a later addition and, ~/.config/ was originally meant to be stuff that may be specific to a single PC, like persisted window layouts for a specific set of monitors, and which would be annoying but not devastating to lose, akin to the non-cache side of Microsoft's local AppData folder.

[byteabit]

Didn’t take long after its creator’s death to start going downhill!

Wrong. This patch is a step up, not down.

[byteabit]

than searching {XDG_CONFIG_HOME, XDG_CACHE_HOME, XDG_DATA_HOME, XDG_STATE_HOME, XDG_RUNTIME_DIR}. Yes, this follows the convention of Linux. But maybe for that case {~/.foo/, ~/foo/config, ~/.foo/cache, ~/foo/state} would've been a better choice?

Then it would still not be better, because there wouldn't be a standard. The idea is to split up the type of files and folders in their respective type of directories. By bundling everything into one folder .foo/ is still not won anything. Even Flatpak splits user data from application data in example. And that's for good reason. ~/ can contain so many other random folders, not just application folders. If you iterate over all folders in ~/ then you don't know if its an application folder, what folders it contain and so on. It makes it complicated. Every application is a snowflake. With XDG you can set the folder for caches to any other folder and all applications store it there (in example on a temporary fast storage). And so on. You know for a fact that every data in XDG_CACHE_HOME can be deleted, without XDG_DATA_HOME being touched. With XDG, you don't need to "search" the files. If you really want delete everything from the program, then just loop over the XDG, that's all.

Edit:
I forgot to mention another thing why XDG rules. In example for a specific application you can dynamically change the environmental XDG variables (through a script) before running it and it would only affect that script/application environment. This can be used for variety of things. It's probably not the normal use case, but always good to have, as it makes the program and environment more flexible.

[szymon_g]

only like 20 something years after it should have done that, but better late than never I guess. Does kde6 uses that directory as well or do they still have crapload of their dotfiles in the home directory?

[byteabit]

Does kde6 uses that directory as well or do they still have crapload of their dotfiles in the home directory?

I don't know if KDE looks up XDG, but it has a configuration file that uses subdirectories such as ".config/plasma-workspace" (dir) or ".config/kdeglobals" (file). In fact many kde application files (such as "kritarc") are put directly under ".config" without a subfolder. The locations for "Downloads" and "Pictures" and so on can be set individually.