[vim/vim] [RFC] .config/vim directory structure (#2034)

[mattn]

Recently, many application store there configuration files into ~/.config/xxx. This is very useful to take-out configuration files into USB-disk or dropbox. As far as I know, many users make symbolic links into ~/Dropbox/config/vim/vimrc from ~/.vimrc or ~/.vim/vimrc.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub

[vyp]

Just a nitpick but should use $XDG_CONFIG_HOME/vim btw. From https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html:

$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

[mattn]

@vyp thanks for the link.

[K.Takata]

If we support it on Unix like systems, maybe we should also support using %USERPROFILE%\AppData\Roaming\vim\ on Windows.

[Christian Brabandt]

this has been discussed before, e.g. here (which includes a patch, perhaps this can be used as a starting point and cleaned up a bit).

[mattn]

Yes, I could not find the discuss. But I think there is meaning this on GitHub.

[Daniel Martí]

Copying from my recent dup, #4275:

Right now, the list of paths to search for the user's vimrc on Linux is:

~/.vimrc
~/.vim/vimrc

I propose that we extend it to:

~/.vimrc
~/.vim/vimrc
$XDG_CONFIG_DIR/vim/vimrc (if the env var is unset, its default is ~/.config)

For some further reading on not cluttering $HOME:

https://web.archive.org/web/20190202170417/https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp
https://ploum.net/207-modify-your-application-to-use-xdg-folders/

[Bram Moolenaar]

> Copying from my recent dup, #4275:
>
> Right now, the list of paths to search for the user's `vimrc` on Linux is:
>
> ```
> ~/.vimrc
> ~/.vim/vimrc
> ```
>
> I propose that we extend it to:
>
> ```
> ~/.vimrc
> ~/.vim/vimrc
> $XDG_CONFIG_DIR/vim/vimrc (if the env var is unset, its default is ~/.config)

> ```

Does this mean that $XDG_CONFIG_DIR/vim is the replacement for ~/.vim
and everything it contains? The XDG spec appears to split things out in
different places, but that might just might things more complicated
without benefit.

> For some further reading on not cluttering $HOME:
>
> https://web.archive.org/web/20190202170417/https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp

Interesting, but it doesn't say why dot files are a bad idea. It
actually says why people started using them (hiding stuff). XDG doesn't
really solve that, just moves it elsewhere. And then there were two
solutions...

> https://ploum.net/207-modify-your-application-to-use-xdg-folders/

It over-simplifies the issue. For me losing my Vim configuration is
like losing an important text file. Like "now I have to reconfigure
Vim" is similar to "now I have to rewrite that letter".

Anyway, so long as supporting XDG can be done in a backwards-compatible
way, that should be fine.

--
A successful man is one who makes more money than his wife can spend.
A successful woman is one who can find such a man.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Kazunobu Kuriyama]

Recently, many application store there configuration files into ~/.config/xxx. This is very useful to take-out configuration files into USB-disk or dropbox.

I'm afraid the issue is not that simple. For example, let's consider the case where both $XDG_CONFIG_HOME/vim and ~/.config/vim are unreadable for some reason. Then where should we go for fallback? Go to $XDG_CONFIG_DIRS/vim and /etc/xdg/vim in that order, and then ~/.vimrc and ~/.vim? The reversed order also looks plausible. The complexity gets multiplied when we take fallback into account. In addition, if $XDG_CONFIG_HOME/vim (or $HOME/.config/vim) is used, people are likely to think they should have $XDG_CACHE_HOME/vim (or $HOME/.cache/vim) and $XDG_DATA_HOME/vim (or $HOME/.local/share/vim) as well. Should we use those directories when $HOME/.config/vim is used? Which files should we put there, backup, swap, undo, view or viminfo? Should we need to change the behavior of 'directory', 'undodir', 'backupdir', 'viewdir', and 'viminfo-n' in accordance with the XDG specs? Again, fallback is also an issue here. The complexity gets multiplied further. To implement the proposed feature fully, quite a few design considerations and decisions must be discussed and addressed.

[chdiza]

Recently, many application store there configuration files into ~/.config/xxx. This is very useful to take-out configuration files into USB-disk or dropbox.

I solve this problem not by asking applications to look in a special dotfolder (much less a special dotfolder with an enforced name that's longer than is desirable), but by making my own dotfolder (".rc") and symlinking some of the things in it into my $HOME. For example, ~/.vim is a symlink to ~/.rc/vim, and ~/.vimrc is symlink to ~/.rc/vimrc. Then when rsyncing backups I only have to include ~/.rc and not myriad dotfiles.

I do this also for lots of other programs. If I ever end up using something that demands ~/.config, I'll just make a symlink called ~/.config that points to ~/.rc.

It's true that I have to set up the symlinks, but it's trivial to script their creation (and their destruction).

But in many years of using and tweaking this setup, I've found that the benefits of keeping frequently modified dotfiles out of $HOME are pretty overrated. If I want to e.g., edit my vimrc, it's much easier to do :e vimrc than :e ~/.rc/vimrc or make sure to have the right file marks in ~/.viminfo. I'd rather have visual clutter in ls -A than make it a PITA to edit my stuff. So even though I can avoid the ~/.vimrc symlink (since vim will check in ~/.vim), I purposefully don't.

Dotfiles that I almost never modify I keep unsymlinked when possible, by using shellvars to point programs inside ~/.rc. E.g., I do this for npmrc, inputrc, the global gitignore/hgignore, and pip.conf.

[Martin Tournoij]

Some people seem to make this a bit more complex than it needs to be
(nuko8's comment, the 2014 patch1).

The only behaviour that really needs to change is loading the initial file.
Pretty much everything else can already be configured manually:

set viminfo+=~/.cache/vim/viminfo
set backupdir=$HOME/.cache/vim/backup | call mkdir(&backupdir, 'p', 0700)
set directory=$HOME/.cache/vim/swap   | call mkdir(&directory, 'p', 0700)
set viewdir=$HOME/.cache/vim/view     | call mkdir(&viewdir, 'p', 0700)
set undodir=$HOME/.cache/vim/undo     | call mkdir(&undodir, 'p', 0700)

I also had to link ~/.cache/vim/pack to ~/.vim/pack (setting packpath didn't
seem to work, but perhaps I did it wrong; didn't look too deeply).

I don't think there is a need for complex confusing behaviour changes, much
less new +xdg_basedir compile flags.

I think this should be straightforward and backwards-compatible:

• Add ~/.config/vim/vimrc to the end of the vimrc search order.
• If ~/.config/vim/vimrc exists, use this directory of ~/.vim as the default
  for runtimepath, packpath, viewdir, and perhaps some other values?

We could discus whether some of this data should be in ~/.local/share or
~/.cache to no end, or adjust the default behaviour for dir and backupdir,
but that will be backwards-incompatible and won't necessarily make things
easier to understand. If you want it stored somewhere else: just change the
settings.

[Marcelo D Montu]

Another approach that could be more flexible would be an extra command line argument with higher precedence on the initialization list.

Currently in Windows I use a batch file to consistently change the $HOME to a thumb drive (even though the %APPDATA% approach should work for some portable platforms, I'm not sure if it would cover all scenarios).

[Kazunobu Kuriyama]

The only behaviour that really needs to change is loading the initial file. Pretty much everything else can already be configured manually:

set viminfo+=~/.cache/vim/viminfo
set backupdir=$HOME/.cache/vim/backup | call mkdir(&backupdir, 'p', 0700)
set directory=$HOME/.cache/vim/swap | call mkdir(&directory, 'p', 0700)
set viewdir=$HOME/.cache/vim/view | call mkdir(&viewdir, 'p', 0700)
set undodir=$HOME/.cache/vim/undo | call mkdir(&undodir, 'p', 0700)

I've already done something like this since I developed the GTK+ 3 GUI for Vim on Mac a few years ago, which is absolutely unnecessary for me only to run Vim there.

I don't think there is a need for complex confusing behaviour changes

I don't, either.

I think this should be straightforward and backwards-compatible:

• Add ~/.config/vim/vimrc to the end of the vimrc search order.

• If ~/.config/vim/vimrc exists, use this directory of ~/.vim as the default for runtimepath, packpath, viewdir, and perhaps some other values?

As to the first item, is it OK for us to ignore any of the contents of the directory $HOME/.config/vim simply because we don't have vimrc there? Some people might want to install their plugins there so that they would comply with the XDG Base Directory Specification as much as they can. What do you say to them? Put an empty vimrc there only for that? Doesn't it sound unnatural?

As to the second item, how do you explain to those who ask why netrw puts its cache files there (Or, does it still put the files in $HOME/.vim?. Unnatural/)? Since that's against the specification, it's quite obvious for us to be going to have questions about the rationale behind it or feature requests to make Vim fully XDG-complicant once the OP is implemented the way you are proposing.

We could discus whether some of this data should be in ~/.local/share or ~/.cache to no end, or adjust the default behaviour for dir and backupdir, but that will be backwards-incompatible and won't necessarily make things easier to understand.

Personally, I think that's because the OP itself was described in an amateur way for some reason, ignoring both the previous discussion on the XDG patch you quoted and the implication or ramification the proposal of the OP would result in. Actually, what I wanted to point out in my previous comment was for the purpose of making our lives easier in the future, avoiding a continual series of questions asking us about "Why Vim doesn't comply with the XDG spec fully while it does use $HOME/.config?". That's why I don't like your proposal.

If you want it stored somewhere else: just change the settings.

Then, why can't you be satisfied only with that together with some symlinks? Why should we need to introduce an incomplete XDG stuff to the Vim core? I can't be happy with that sort of incompleteness or inconsistency.

[Martin Tournoij]

Another approach that could be more flexible would be an extra command
line argument with higher precedence on the initialization list.

But then I need to add a shell alias for Vim, right?

is it OK for us to ignore any of the contents of the directory
$HOME/.config/vim simply because we don't have vimrc there?

I'd say that's fine.

Some people might want to install their plugins there so that they would
comply with the XDG Base Directory Specification as much as they can.
What do you say to them? Put an empty vimrc there only for that? Doesn't
it sound unnatural?

You already can by setting packpath or runtimepath to ~/.cache/vim or
whatever you want in your vimrc. I already do this right now. No need for
confusing init logic, supporting a whole bunch of directories, or empty
vimrc files.

I don't know about netrw, or what kind of files it keeps. Would losing all
of those be a disaster, or would it be "transparent" like a web browser's
cache? If it's the latter, it can probably be changed to ~/.cache/vim. If
it's the former, ~/.config/vim makes more sense.

avoiding a continual series of questions asking us about "Why Vim doesn't
comply with the XDG spec fully while it does use $HOME/.config?".

It would follow the XDG spec though. Arguably, the only exception is
packpath, and you could make a case that plugins in Vim are just config
files. XDG spec is not very clear on what is a "data file".

From a UX perspective it certainly makes sense to keep pack in ~/.config/vim
instead of ~/.local/share/vim. Who cares what some spec says? We can just do
what makes the most sense for Vim.

By the way, I'm pretty sure that there will be a "continual series of
questions" asking about "I removed all plugins in ~/.vim/pack and I still
have :CommandFromPlugin, what gives?" and the like if Vim will check in
both ~/.vim/pack and ~/.config/vim/pack.

Signalling "this is the user's vim directory" with a vimrc is by far the
least confusing, especially since this is how Vim has behaved for decades.

[﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽﷽]

From a UX perspective it certainly makes sense to keep pack in ~/.config/vim
instead of ~/.local/share/vim. Who cares what some spec says? We can just do
what makes the most sense for Vim.

The thing is that a big advantage of spec complicance is that people can just backup $XDG_CONFIG_HOME/~/.config without having to add exceptions for all the noncompliant applications like vim. I've seen that complaint a lot whenever applications just dump everything in the config folder.

[Jason Karns]

It seems that many references to XDG imply that supporting $XDG_CONFIG_HOME/vim would be sufficient to support the XDG spec. However, full spec compliance requires looking not only in XDG_CONFIG_HOME/vim, but also all of XDG_CONFIG_DIRS/vim (where XDG_CONFIG_DIRS is colon-separated paths). And each of XDG_CONFIG_HOME, XDG_CONFIG_DIRS have spec-defined fallbacks when the variables are unset or empty.

I would only ask that if vim implements support for XDG basedir spec, that it support the full spec (both XDG_CONFIG_HOME and XDG_CONFIG_DIRS) and not only the "naive" XDG_CONFIG_HOME implementation.

[Martin Tournoij]

From a UX perspective it certainly makes sense to keep pack in ~/.config/vim
instead of ~/.local/share/vim. Who cares what some spec says? We can just do
what makes the most sense for Vim.

The thing is that a big advantage of spec complicance is that people can just backup $XDG_CONFIG_HOME/~/.config without having to add exceptions for all the noncompliant applications like vim. I've seen that complaint a lot whenever applications just dump everything in the config folder.

My point was mostly that you can infinitely argue and split hairs over some vaguely worded specification, but in the end it's probably better to have a discussion about what the most useful/best thing is, rather than what some spec says.

[BilLOPGVkPPn8z0JGJhgiAGNo9YAqpk5ruChl0F]

My point was mostly that you can infinitely argue and split hairs over some vaguely worded specification, but in the end it's probably better to have a discussion about what the most useful/best thing is, rather than what some spec says.

Yeah I like what you've proposed so far, it seems to partially respect the spec while making backwards compatibility easy. Full spec respecc seems impossible without breaking tradition. Just wanted to bring up a common compliant I hear all the time in response to your comment about UX in general.

[Lyle Hanson]

Some people seem to make this a bit more complex than it needs to be [...]

The only behaviour that really needs to change is loading the initial file.
Pretty much everything else can already be configured manually:

set viminfo+=~/.cache/vim/viminfo
set backupdir=$HOME/.cache/vim/backup | call mkdir(&backupdir, 'p', 0700)
set directory=$HOME/.cache/vim/swap   | call mkdir(&directory, 'p', 0700)
set viewdir=$HOME/.cache/vim/view     | call mkdir(&viewdir, 'p', 0700)
set undodir=$HOME/.cache/vim/undo     | call mkdir(&undodir, 'p', 0700)

I would argue that requiring explicit manual configuration is more complex than it needs to be. The simplest possible implementation would be to default to the sane standards-compliant locations and not require the user to do anything at all.

I don't think there is a need for complex confusing behaviour changes, much
less new +xdg_basedir compile flags.

Agreed; look for files in their XDG-specified locations, fall back to the legacy locations if nothing is found. No compile-time flag needed.

I think this should be straightforward and backwards-compatible:

* Add ~/.config/vim/vimrc to the end of the vimrc search order.

* If ~/.config/vim/vimrc exists, use this directory instead of ~/.vim as the default
  for runtimepath, packpath, viewdir, and perhaps some other values?

Nitpick: specifying ~/.config implies what I see as a misunderstanding about why the XDG spec is so useful, as @brammool 's comment of "XDG doesn't really solve that, just moves it elsewhere" seems to also imply. The benefit of respecting the specification isn't just to put it "somewhere else", it's to put it where I want it, without having to repeat myself every time I install anything. Forgive the following explanation if I misrepresent your position, but I've encountered similar confusion on enough other projects that I think it's worth a bit of a user story for those who don't understand:

If I've never heard of XDG and don't particularly care where a program stores its files, I may eventually get around to trying to back up and/or version control my configuration files without hauling around everything else on my drive and I'll be delighted that most of them seem to be in ~/.config. When I have to add exceptions and regex matches for every program which stores its files in what seem to me to like a jumble of random locations, the fact that a given program has done it that way for 30 years doesn't make my job any easier or less frustrating than for a program that was written last week without knowing any better.

If, on the other hand, I've gone out of my way to express a preference by setting export XDG_CONFIG_HOME="/mnt/configs", my scripts will be just as broken if files are blindly put into ~/.config as they would be for files in ~/.very_cool_program/everything.lol/. Or let's say I'm a journalist or activist working inside a regime hostile to my opinions, and I want to make doubly sure I delete $XDG_CACHE_HOME every time I lock my computer. Every program which respects that preference is one less I have to worry about leaking information which could be potentially threatening to my safety and freedom without relying on my ability to scour manpages and documentation to work out where every program stores every file.

From a UX point of view, I'd rather express my preferences at most once (and by inaction I still reap the benefits), and still be able to leverage reasonable assumptions later as my file management habits evolve than to have to express my preferences n * m times, where n is the number of programs I use and m is the number of unique configuration options each of them exposes to specify where all of their files go. Given the cumulative benefits on offer and the relatively small effort required from maintainers to leverage them, not punting that burden onto every individual user seems like an obvious win given the fact that other alternatives already provide this option.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[IFo Hancroft]

@brammool Basically, configs should go in $XDG_CONFIG_HOME/vim/, data in $XDG_DATA_HOME/vim/, logs in $XDG_CACHE_HOME, etc... I mean you already know the spec.

The way I am understanding the current Vim structure (unless I am mistaking what files there are and what they are) ~/.vimrc should become $XDG_CONFIG_HOME/vim/vimrc, ~/.vim should become $XDG_DATA_HOME/vim/ and ~/.viminfo should become $XDG_CACHE_HOME/vim/viminfo

The fallback/backwards compatibility should be:

• Configs:
  • $XDG_DATA_HOME/vim/ (if variable empty or unset check or unreadable/unwritable depending on whether you are trying to read or write to it, continue to the next location)
  • ~/.config/vim/
  • ~/.vimrc
  • The folders in $XDG_CONFIG_DIRS (the variable for the place/s for the system wide configs) with the first path in the variable having precedence over the second, second over the third, etc
  • What Vim currently uses for system-wide config

It's pretty much the same procedure for data and cache but with their own variables.
Unless I am forgetting something, Vim already has data, cache and config separate, but they are all in the home dir.

P.S. The current existing workarounds of making Vim respect the XDG spec don't work. I have tried that and it causes problems in some very specific and weird cases (I can't remember them anymore. I reverted to having everything under home when I discovered this was the cause for the problems)

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Jason Karns]

@ifohancroft typo under the configs bullet (first bullet point should be config home, not data)

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[IFo Hancroft]

@ifohancroft typo under the configs bullet (first bullet point should be config home, not data)

Thank you! Fixed it now.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[zerdox]

I guess there are workarounds for all files except .viminfo for now.
Can't wait for closing this issue. Tired of trash in my home directory

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Christian Brabandt]

You can set the viminfofile option

Am 24.04.2021 um 12:37 schrieb zerdox <notifi...@github.com>:



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/vim/vim/issues/2034/826072545%40github.com.

[txtsd]

What's the holdup on this? Seems like an easy fix, and no one should have any problems with adhering to freedesktop specs.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Christian Brabandt]

What's the holdup on this? Seems like an easy fix, and no one should have any problems with adhering to freedesktop specs.

Perhaps someone doing the actual work, updating the documentation and the source code?

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[txtsd]

What's the holdup on this? Seems like an easy fix, and no one should have any problems with adhering to freedesktop specs.

Perhaps someone doing the actual work, updating the documentation and the source code?

Since 2017?

[Christian Brabandt]

Since 2017?

Yes, issues tend to be discussed to death, with everybody knowing it better but nobody actually doing the work. But code speaks louder than words. So here is your chance to contribute to a well-known open source project 😄

[txtsd]

I'm looking at the code, and the logic is done with ifdefs like over here: https://github.com/vim/vim/blob/c54f347d63bcca97ead673d01ac6b59914bb04e5/src/os_unix.h#L269

[Bruno Bronosky]

Some people seem to make this a bit more complex than it needs to be (nuko8's comment, the 2014 patch1).

The only behaviour that really needs to change is loading the initial file. Pretty much everything else can already be configured manually

Exactly this! Can we please stop the bike shed and yak shaving exercises and address the single issue that matters? That issue is: make the .vimrc file relocatable and all other locations definable within it.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1114458421@github.com>

[Bram Moolenaar]

I'm afraid that the more I read about the XDG so-called standard the more questions pop up.
Hardly anything is said about how to handle conflicts, naming, restrictions, etc.
In general, it's a "you'll have to guess how it really works" kind of standard.
And the fallback (no environment variables defined) still has to be implemented, thus it suffers from the "yet another standard" syndrome. https://xkcd.com/927/
I see no reason to support anything of the XDG standard until it actually is a standard.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1117801530@github.com>

[Nick Jensen]

While I agree that the XDG standard is confusing and it's difficult to know what to put where, I would think that this could safely be done in stages, rather than an all-or-nothing approach.

When loading vim on unix, if either $XDG_CONFIG_HOME/vim or ~/.config/vim directories exist, then use those instead of ~/.vim. On Windows, if %APPDATA%\Vim exists, use it instead of %HOMEPATH%\vimfiles.

That's a small change would allow users who care about this to move their configs out of home without much fuss, and everything else can be manually configured from users' $XDG_CONFIG_HOME/vim/vimrc files. Actually getting vim to use these locations and other XDG conventions by default could be a matter for another day, if ever.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1117927851@github.com>

[blake]

I'm afraid that the more I read about the XDG so-called standard the more questions pop up. Hardly anything is said about how to handle conflicts, naming, restrictions, etc. In general, it's a "you'll have to guess how it really works" kind of standard. And the fallback (no environment variables defined) still has to be implemented, thus it suffers from the "yet another standard" syndrome. https://xkcd.com/927/ I see no reason to support anything of the XDG standard until it actually is a standard.

Delusional...

Everything else supports this. Use Neovim folks.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1118032230@github.com>

[Bram Moolenaar]

Nick Jensen wrote:

> While I agree that the XDG standard is confusing and it's difficult to
> know what to put where, I would think that this could safely be done
> in stages, rather than an all-or-nothing approach.
>
> When loading vim on unix, if either `$XDG_CONFIG_HOME/vim` or

> `~/.config/vim` directories exist, then use those instead of `~/.vim`.

> On Windows, if `%APPDATA%\Vim` exists, use it instead of

> `%HOMEPATH%\vimfiles`.

>
> That's a small change would allow users who care about this to move
> their configs out of home without much fuss, and everything else can
> be manually configured from users' `$XDG_CONFIG_HOME/vim/vimrc` files.
> Actually getting vim to use these locations and other XDG conventions
> by default could be a matter for another day, if ever.

This is not a small change, and it will annoy users who are not aware of
how this works.

There are several things that can go wrong:
- User was always using ~/.vimrc, for some reason $XDG_CONFIG_HOME gets
set and Vim looks for ~/.config/vim/vimrc, but can't find it.
- User relies on $XDG_CONFIG_HOME to be set, but somehow it gets changed
or cleared, Vim can't find the "vim" directory.
- $XDG_CONFIG_HOME is set, but user edits ~/.vimrc and wonders why the
changes are not being picked up.
- Etc.

In programming using global variables is frowned upon, because it can
cause trouble. Environment variables are like global variables, they
are shared between all applications and can cause trouble, unless used
carefully. In my opinion XDG should not have been implemented with
environment variables.

The argument that neovim does this doesn't really matter, when switching
to neovim people know things are going to be different. When sticking
with Vim a sudden different behavior is not anticipated.

--
hundred-and-one symptoms of being an internet addict:
96. On Super Bowl Sunday, you followed the score by going to the
Yahoo main page instead of turning on the TV.

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1118467285@github.com>

[mattn]

Use Neovim folks

Well, I voted for this issue, but I don't like such comments. Please do constructive comments.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1118490979@github.com>

[Jason Papakostas]

• User was always using ~/.vimrc, for some reason $XDG_CONFIG_HOME gets set and Vim looks for ~/.config/vim/vimrc, but can't find it.

• $XDG_CONFIG_HOME is set, but user edits ~/.vimrc and wonders why the changes are not being picked up.

This is not how it should work. You can still fall back to searching in the legacy config path when $XDG_CONFIG_HOME is set

• User relies on $XDG_CONFIG_HOME to be set, but somehow it gets changed or cleared, Vim can't find the "vim" directory.

This truly isn't vim's problem to worry about

---

I believe the logic should be something like this pseudocode:

function getConfigPath() {

  var legacyConfigPath = '~/.vimrc'

  var xdgConfigHome = env.XDG_CONFIG_HOME || '~/.config'

  var xdgConfigPath = xdgConfigHome + '/vim/vimrc'



  var possibleConfigs = [xdgConfigPath, legacyConfigPath]

  var existentConfigs = possibleConfigs.filter(fileExists)

  

  if existentConfigs.length == 0

    return null



  if existentConfigs.length > 1

     warn(`using config at ${existentConfigs[0]}, ignoring additional config(s) at ${existentConfigs[1..]}`)

  

  return existentConfigs[0]

}

The config file can be present in the legacy location or the XDG location. One will have precedence over the other (which one gets higher priority doesn't really matter).

---

In programming using global variables is frowned upon, because it can
cause trouble. Environment variables are like global variables, they
are shared between all applications and can cause trouble, unless used
carefully. In my opinion XDG should not have been implemented with
environment variables.

Every vim setting is a global variable too. Good and bad is not so black and white. 😛

Another thing that's frowned upon: hard-coding options that have some value in being configurable

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1118563873@github.com>

[IFo Hancroft]

While I agree that the XDG standard is confusing and it's difficult to know what to put where, I would think that this could safely be done in stages, rather than an all-or-nothing approach.

When loading vim on unix, if either $XDG_CONFIG_HOME/vim or ~/.config/vim directories exist, then use those instead of ~/.vim. On Windows, if %APPDATA%\Vim exists, use it instead of %HOMEPATH%\vimfiles.

That's a small change would allow users who care about this to move their configs out of home without much fuss, and everything else can be manually configured from users' $XDG_CONFIG_HOME/vim/vimrc files. Actually getting vim to use these locations and other XDG conventions by default could be a matter for another day, if ever.

While I agree that it can be implemented in stages (and I'd love for the XDG Basedir spec to be implemented (in full)), while also still supporting the current directory for backwards compatiblity, I don't see why it should be the last place to search.

In my opinion, it should first search for ~/.vimrc and if present, stop there and use it.
If not, then start with the XDG part.

Same with the system wide directory - use the current one first, if the files are not there, then look in the XDG systemwide config dirs.

While I agree that the XDG Basedir spec is confusing in places (and in some somewhat contradicting) and there are things that need to be answered or clarified, in general for most cases it's actually quite straightforward:

• Config
  • System-wide: Is $sysconfdir set? If set - put the config files inside $sysconfdir/xdg/vim/. If not set - put config files under /etc/xdg/vim/ - if neither exists or is not writable/readable (you get my point, if you can't put the files there or you can't find them there or can't read them) - not your fault at this point, throw an error (this last part is my opinion as not mentioned by the spec but I think that's the obvious choice)
  • User: Is $XDG_CONFIG_HOME set? If set - plate config files inside $XDG_CONFIG_HOME/vim/. If not set - check if $XDG_CONFIG_DIRS is set and go through the directories there, using the first one you can. If not - default to $HOME/.config/vim/

It's the same thing with the directories for the state files, for the runtime files, for the cache, etc..

In the case of the runtime directory, I have a gripe with not being provided a way to check if a similar directory exists as the requirements for that directory are very specific..

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1119013416@github.com>

[Alexandru Guzinschi]

There are several things that can go wrong: - User was always using ~/.vimrc, for some reason $XDG_CONFIG_HOME gets set and Vim looks for ~/.config/vim/vimrc, but can't find it. - User relies on $XDG_CONFIG_HOME to be set, but somehow it gets changed or cleared, Vim can't find the "vim" directory. - $XDG_CONFIG_HOME is set, but user edits ~/.vimrc and wonders why the changes are not being picked up. - Etc.

@brammool If $XDG_CONFIG is the last place where vim should look for its files (i.e: after failed to load ~/.vimrc), could cause any issues?
That way I'm thinking that the user must knowingly not create a ~/.vimrc and create a ~/.config/vim/vimrc, which should not create any issues for current configurations.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1120372827@github.com>

[Bram Moolenaar]

Alexandru Guzinschi wrote:

> > There are several things that can go wrong: - User was always using
> > ~/.vimrc, for some reason $XDG_CONFIG_HOME gets set and Vim looks
> > for ~/.config/vim/vimrc, but can't find it. - User relies on
> > $XDG_CONFIG_HOME to be set, but somehow it gets changed or cleared,
> > Vim can't find the "vim" directory. - $XDG_CONFIG_HOME is set, but
> > user edits ~/.vimrc and wonders why the changes are not being picked
> > up. - Etc.
>
> @brammool If $XDG_CONFIG is the last place where vim should look for

> its files (_i.e: after failed to load ~/.vimrc_), could cause any
> issues?
> That way I'm thinking that the user must **knowingly** not create a

> ~/.vimrc and create a ~/.config/vim/vimrc, which should not create any
> issues for current configurations.

Why not put this in ~/.vimrc:

source ~/.config/vim/vimrc

Or, assuming $XDG_CONFIG is set:

source $XDG_CONFIG/vim/vimrc

--
hundred-and-one symptoms of being an internet addict:

135. You cut classes or miss work so you can stay home and browse the web.

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1120437719@github.com>

[Daniel Martí]

@brammool one of the advantages of XDG_CONFIG_HOME is that one doesn't need to clutter HOME with "dot files". Having a placeholder file that sources another file, or a symbolic link, undoes that.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1120440659@github.com>

[Lyle Hanson]

And just to preempt the latest refrain of "but it's just one file and it's been there a long time": sure, this is just one file. And that's what every other app thinks, too. But as a user who wants to back up and/or version control my config files, I can't just do that for ${XDG_CONFIG_HOME}, I have to do that for ${XDG_CONFIG_HOME}, and /.special_snowflake_1, /.special_snowflake_2`, etc. Now that most other applications are starting to respect users' preferences, the remaining snowflakes really stand out.

I'm convinced that there is no novel new argument against supporting users' preferences that hasn't already been addressed in this issue. Rather than continue to rehash the same concerns for another five years, I think we really just need a patch for people to try out that hopefully addresses their concerns. I suspect that why we don't see that happening is that nobody wants to invest time into a feature that, however popular, the maintainers don't express any interest in being receptive to.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1121162146@github.com>

[James Haslam]

A good template is to simply copy the behaviour that .gitconfig uses.
Behaviour described here.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1136536034@github.com>

[Kreijstal]

Drop down the ego, just allow people to put their config wherever they want

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1191250534@github.com>

[Sergio Miguéns]

And just to preempt the latest refrain of "but it's just one file and it's been there a long time": sure, this is just one file. And that's what every other app thinks, too. But as a user who wants to back up and/or version control my config files, I can't just do that for ${XDG_CONFIG_HOME}, I have to do that for ${XDG_CONFIG_HOME}, AND ~/.special_snowflake_1_rc, AND ~/.special_snowflake_2_rc, etc. Now that most other applications are starting to respect users' preferences, the remaining snowflakes really stand out.

I'm convinced that there is no novel new argument against supporting users' preferences that hasn't already been addressed in this issue. Rather than continue to rehash the same concerns for another five years, I think we really just need a patch for people to try out that hopefully addresses their concerns. I suspect that why we don't see that happening is that nobody wants to invest time into a feature that, however popular, the maintainers don't express any interest in being receptive to. I started to work on @txtsd's patch for a little while before cynically concluding that until I think my effort has any hope of being merged I can just keep using another text editor with a similar name that already has this feature.

Same, it is infuriating since some packages have a vim dependency and I have to get it installed for them, so if I could I would use what I already have, but man, that vimrc file stands out in my home! I really don't see the problem with allowing the users to change the path of the file, but it is not my program so I won't debate it. I'll take two almost identical programs installed over having random config files cluttering my home folder.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1248151883@github.com>

[suliveevil]

XDG is more like a method to clean up the $HOME that puts things into bedroom and kitchen based on classification IMO.

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/1279898976@github.com>

[Christian Brabandt]

Closed #2034 as completed via c9df1fb.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/2034/issue_event/12461284952@github.com>

[txtsd]

Thank you @chrisbra!

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/2058163700@github.com>

[Ali Bazrafshan]

@chrisbra This issue is closed but %APPDATA% support for Windows is not added yet.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/2254496254@github.com>

[Christian Brabandt]

correct. I have mentioned it before, I have no intention to add this yet to Vim. I personally hate using the %APPDATA% directory, as I can never find which of the various directories is the correct one (and I usually forget to back this one up)

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/2254539640@github.com>

[Kreijstal]

@chrisbra This issue is closed but %APPDATA% support for Windows is not added yet.

if you want it in appdata just set the env variable $XDG_CONFIG_HOME to appdata no?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/2255167756@github.com>

[Christian Brabandt]

no XDG_CONFIG_HOME is not supported on Windows

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/2255173355@github.com>

[Kreijstal]

sad

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/2255179549@github.com>

[Kelvin M. Klann]

@chrisbra on Jul 28:

I have mentioned it before, I have no intention to add this yet to Vim. I
personally hate using the %APPDATA% directory, as I can never find which of
the various directories is the correct one (and I usually forget to back this
one up)

Same; I remember some programs using %UserProfile%/.config/foo on Windows.
It would be nice if this was more common for CLI programs, at least when
compared to using %UserProfile%/.foo.

Thoughts on using $XDG_CONFIG_HOME on all platforms?

If the variable is set, I'd assume that the user intends for it to be used.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/2256682114@github.com>

[Ali Bazrafshan]

It can be added as a fallback directory for users who are not confused about it.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/2266641400@github.com>

[SWCurragh]

! [The pin code is 990440211740641219] (https://github.com/user-attachments/assets/8833b0d8-ad34-45a0-9e13-869b220bb0f3)

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/2327795770@github.com>

[D. Ben Knoble]

For the mailing list: the previous message looks very suspicious and has been deleted on GitHub.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/2034/2329741144@github.com>