New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support XDG directory specification #78

Closed
ZyX-I opened this Issue Feb 23, 2014 · 88 comments

Comments

Projects
None yet
@ZyX-I
Contributor

ZyX-I commented Feb 23, 2014

From #26, but I am talking not only about configuration files.

  1. Configuration:
    1. populate runtimepath from XDG_CONFIG_DIRS, XDG_DATA_DIRS, XDG_DATA_HOME and XDG_CONFIG_HOME (and $VIMRUNTIME as well):

      $XDG_CONFIG_HOME/nvim
      $xdg_config_dir/nvim (for each directory in $XDG_CONFIG_DIRS)
      $XDG_DATA_HOME/nvim
      $xdg_data_dir/nvim/site (for each directory in $XDG_DATA_DIRS)
      $VIMRUNTIME (looks something like /usr/share/nvim/runtime)
      $xdg_data_dir/nvim/site/after (for each directory in $XDG_DATA_DIRS, reverse order)
      $XDG_DATA_HOME/nvim
      $xdg_config_dir/nvim/after (for each directory in $XDG_CONFIG_DIRS, reverse order)
      $XDG_CONFIG_HOME/nvim/after

    2. init.vim should be taken from the first directory in $XDG_CONFIG_HOME:$XDG_CONFIG_DIRS where it was found (e.g. first from ~/.config/nvim/init.vim, then from /etc/xdg/nvim/init.vim).

  2. Default &directory option (it holds swap files there) to $XDG_DATA_HOME/nvim/swap//.
  3. Default &backupdir to .,$XDG_DATA_HOME/nvim/backup.
  4. Default &undodir to $XDG_DATA_HOME/nvim/undo//.
  5. Default ShaDa location is $XDG_DATA_HOME/nvim/shada/main.shada.
  6. Default &viewdir to $XDG_DATA_HOME/nvim/view.

OS defaults:

  1. On nix operating systems default XDG_ variables according XDG base directory specification.
  2. On windows default XDG_CONFIG_HOME and XDG_DATA_HOME to %APPDATA%, XDG_CACHE_HOME and XDG_RUNTIME_DIR to %TEMP% (just in case) and XDG_CONFIG_DIRS to empty (as VIMRUNTIME is handled separately).

Some other notes:

  1. In any case respect existing values on any operating system.
  2. Entry separator is a colon on any system. It is expected that path separator is a forward slash inside these variables on systems where path separator is a colon.
  3. On startup absent environment variables (only XDG_CONFIG_HOME and XDG_DATA_HOME) should be set to their default values for use in scripts. Code that sets default options this will not have to handle this on its own.
  4. On startup invalid values (XDG base directory specification says that paths must be absolute, relative paths are to be ignored) are replaced with default ones.
  5. Code that sets those variables should live in src/nvim/os/env.c, alongside with restored init_homedir (which currently lives in misc1.c and lacks code for Windows).

Note some renamings: vim74 to 7.4, vimfiles to site-contrib, .vimrc to init.vim. Reasoning behind this: to avoid duplicating data. We already know this directory contains files for neovim since it is named /usr/share/nvim, why should this information be repeated in the subdirectory? Also it is hard to tell from the directory name what is the difference in vim74 and vimfiles contents, but it is easy for 7.4 and site-contrib (names are taken from /usr/share/zsh). Extension designates file type, so no need to remove it, it is for separate purpose.

Update: Renamed rc.vim to startup.vim. Reasoning: this way config file name resembles its purpose. See also #235.

Update 2:

  • Renamed neovim to nvim as it is new convention.
  • Moved &directory, &backupdir and &undodir defaults to $XDG_DATA_HOME.
  • Made &undodir use trailing // as well.
  • Removed ~/tmp/$TEMP/etc defaults from &backupdir (backups in %TEMP%?!).
  • Removed current directory from &undodir default. If &backupdir was supporting trailing // I would happily remove current directory from there as well: nobody likes spamming working directory with files that are needed only by vim and hardly ever by user.

Update 3: All options sharing the same $XDG_DATA_HOME/nvim directory were supplied with distinct subpaths.

Update 4: Added OS defaults and notes.

Update 5: Renamed startup.vim to init.vim.

Update 6: Added default for ShaDa.

Update 7: Added default for viewdir.

Update 8: Updated init.vim search path, as discussed in some of the PRs.

@liamim

This comment has been minimized.

Show comment
Hide comment
@liamim

liamim commented Feb 23, 2014

👍

@ashleyh

This comment has been minimized.

Show comment
Hide comment
@ashleyh

ashleyh Feb 23, 2014

Contributor

👍

Contributor

ashleyh commented Feb 23, 2014

👍

@thiderman

This comment has been minimized.

Show comment
Hide comment
@thiderman

thiderman Feb 23, 2014

Contributor

👍

Contributor

thiderman commented Feb 23, 2014

👍

@vheon

This comment has been minimized.

Show comment
Hide comment
@vheon

vheon Feb 24, 2014

Contributor

👍

Contributor

vheon commented Feb 24, 2014

👍

@scott-linder

This comment has been minimized.

Show comment
Hide comment
@scott-linder

scott-linder Feb 24, 2014

Contributor

👍 long overdue

Contributor

scott-linder commented Feb 24, 2014

👍 long overdue

@Soares Soares referenced this issue Feb 25, 2014

Closed

Use XDG base dir #126

@Earnestly

This comment has been minimized.

Show comment
Hide comment
@Earnestly

Earnestly Feb 26, 2014

Definitely needed

Earnestly commented Feb 26, 2014

Definitely needed

@tssm

This comment has been minimized.

Show comment
Hide comment
@tssm

tssm Feb 26, 2014

  1. Move .viminfo to $XDG_CACHE_HOME/neovim/info.

tssm commented Feb 26, 2014

  1. Move .viminfo to $XDG_CACHE_HOME/neovim/info.
@tssm

This comment has been minimized.

Show comment
Hide comment
@tarruda

This comment has been minimized.

Show comment
Hide comment
@tarruda

tarruda Apr 4, 2014

Member

I think we should take the approach suggested in #460 and delegate it to an external tool. In any case we can revisit this later

Member

tarruda commented Apr 4, 2014

I think we should take the approach suggested in #460 and delegate it to an external tool. In any case we can revisit this later

@tarruda tarruda closed this Apr 4, 2014

@tarruda tarruda added the reopen-later label Apr 5, 2014

@kopischke

This comment has been minimized.

Show comment
Hide comment
@kopischke

kopischke Apr 6, 2014

@tarruda I think you might be misunderstanding what this is about: the XDG Base Directory Specification is meant to stop applications from littering the user’s home dir with configuration files and directories by offering a common, configurable set of base directories for these. In the case of Vim, we are talking about .vim, .vimrc, .gvimrc, the default values for rtp, plus anything set in directory, backupdir and the viminfo n argument. At least when it comes to its own initialisation files and to the defaults it sets, the application needs to support the XDG scheme natively to work (no, exporting shell vars is not a solution – MacVim for instance does not read them, due to the way OS X handles environment settings for GUI applications; other GUI front ends might gave similar problems). In short, this is not something that can, or should, be delegated to a helper app.

@ZyX-I good call, but swap files should not be put in $XDG_RUNTIME_DIR, as the persistence of that directory is not guaranteed. Per the spec:

Applications should use this directory for communication and synchronization purposes and should not place larger files in it, since it might reside in runtime memory and cannot necessarily be swapped out to disk.

kopischke commented Apr 6, 2014

@tarruda I think you might be misunderstanding what this is about: the XDG Base Directory Specification is meant to stop applications from littering the user’s home dir with configuration files and directories by offering a common, configurable set of base directories for these. In the case of Vim, we are talking about .vim, .vimrc, .gvimrc, the default values for rtp, plus anything set in directory, backupdir and the viminfo n argument. At least when it comes to its own initialisation files and to the defaults it sets, the application needs to support the XDG scheme natively to work (no, exporting shell vars is not a solution – MacVim for instance does not read them, due to the way OS X handles environment settings for GUI applications; other GUI front ends might gave similar problems). In short, this is not something that can, or should, be delegated to a helper app.

@ZyX-I good call, but swap files should not be put in $XDG_RUNTIME_DIR, as the persistence of that directory is not guaranteed. Per the spec:

Applications should use this directory for communication and synchronization purposes and should not place larger files in it, since it might reside in runtime memory and cannot necessarily be swapped out to disk.

@vially

This comment has been minimized.

Show comment
Hide comment
@vially

vially Jun 14, 2014

Completely agree with @kopischke
I don't think this should be delegated to a helper app.

Using a wrapper around the vim executable just so it can read the configuration files from the correct paths does not sound like a sensible option.

vially commented Jun 14, 2014

Completely agree with @kopischke
I don't think this should be delegated to a helper app.

Using a wrapper around the vim executable just so it can read the configuration files from the correct paths does not sound like a sensible option.

@mrak

This comment has been minimized.

Show comment
Hide comment
@mrak

mrak Jun 14, 2014

Please support this. It is what compliant Unix citizens are adopting. Neovim is attempting to be a modernization of vim, so I think this qualifies.

Thanks for all of the other awesome y'all are bringing! Looking forward to the first release.

mrak commented Jun 14, 2014

Please support this. It is what compliant Unix citizens are adopting. Neovim is attempting to be a modernization of vim, so I think this qualifies.

Thanks for all of the other awesome y'all are bringing! Looking forward to the first release.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Jun 14, 2014

Member

Vim itself will be adding support for this pretty soon, so we'll probably just merge that.

Member

justinmk commented Jun 14, 2014

Vim itself will be adding support for this pretty soon, so we'll probably just merge that.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jun 14, 2014

Contributor

@justinmk I do not like this idea. Vim support will be optional, falling back to old behaviour because Vim cannot drop backwards compatibility. We can make XDG directories the only default variant since we do not have to be compatible with Vim configuration locations.

I do not see any sense in having two default locations for user configuration.

Contributor

ZyX-I commented Jun 14, 2014

@justinmk I do not like this idea. Vim support will be optional, falling back to old behaviour because Vim cannot drop backwards compatibility. We can make XDG directories the only default variant since we do not have to be compatible with Vim configuration locations.

I do not see any sense in having two default locations for user configuration.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Jun 14, 2014

Member

@ZyX-I you don't want to support ~/.nvimrc?

Member

justinmk commented Jun 14, 2014

@ZyX-I you don't want to support ~/.nvimrc?

@aktau

This comment has been minimized.

Show comment
Hide comment
@aktau

aktau Jun 14, 2014

Member

@ZyX-I you don't want to support ~/.nvimrc?

That's what I read as well. On the face of it, I'm not really in favour of removing support for .*vimrc whenever the XDG path is not found.

Member

aktau commented Jun 14, 2014

@ZyX-I you don't want to support ~/.nvimrc?

That's what I read as well. On the face of it, I'm not really in favour of removing support for .*vimrc whenever the XDG path is not found.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jun 14, 2014

Contributor

Why should I want it?

That's what I read as well. On the face of it, I'm not really in favour of removing support for .*vimrc whenever the XDG path is not found.

Why? If one wants to have it there there are shell aliases, variables like VIMINIT (perhaps should be renamed to NVIMINIT), MYVIMRC (did we drop support for it? MYNVIMRC and MYVIMRC seem not to work), system-wide configuration (which is to be placed in /etc/xdg/nvim, but since it the package maintainers business its location is completely irrelevant), … Supporting both XDG base directory specification and non-XDG .nvimrc path is like saying “we do not know where you should put your configuration”. There must be one default and there must be ways to omit using it, but there should not be two defaults.

If we do support Vim directories for some reasons this is a separate issue, but currently this is not the case.

Contributor

ZyX-I commented Jun 14, 2014

Why should I want it?

That's what I read as well. On the face of it, I'm not really in favour of removing support for .*vimrc whenever the XDG path is not found.

Why? If one wants to have it there there are shell aliases, variables like VIMINIT (perhaps should be renamed to NVIMINIT), MYVIMRC (did we drop support for it? MYNVIMRC and MYVIMRC seem not to work), system-wide configuration (which is to be placed in /etc/xdg/nvim, but since it the package maintainers business its location is completely irrelevant), … Supporting both XDG base directory specification and non-XDG .nvimrc path is like saying “we do not know where you should put your configuration”. There must be one default and there must be ways to omit using it, but there should not be two defaults.

If we do support Vim directories for some reasons this is a separate issue, but currently this is not the case.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jun 14, 2014

Contributor

By the way, Vim is the only software I know which supports more then one configuration location. But this support is based on historical reasons and POSIX compliance. This is not the case here:

  1. Neovim is a new project without releases: no own compatibility reasons.
  2. Neovim is not supporting Vim directories and in any case Vim does not support ~/.nvimrc: no other compatibility reasons.
  3. Neovim is dropping Vi compatibility options in #228: no POSIX compliance (and in any case POSIX does not require us to source .nvimrc).

Based on this facts I think it is required that you will be explaining why if XDG specification is supported ~/.nvimrc should be supported as well, not me explaining why it should not be supported: if XDG specification is supported it is about having additional code to support .nvimrc, not about having additional code to not support it.

Contributor

ZyX-I commented Jun 14, 2014

By the way, Vim is the only software I know which supports more then one configuration location. But this support is based on historical reasons and POSIX compliance. This is not the case here:

  1. Neovim is a new project without releases: no own compatibility reasons.
  2. Neovim is not supporting Vim directories and in any case Vim does not support ~/.nvimrc: no other compatibility reasons.
  3. Neovim is dropping Vi compatibility options in #228: no POSIX compliance (and in any case POSIX does not require us to source .nvimrc).

Based on this facts I think it is required that you will be explaining why if XDG specification is supported ~/.nvimrc should be supported as well, not me explaining why it should not be supported: if XDG specification is supported it is about having additional code to support .nvimrc, not about having additional code to not support it.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jun 14, 2014

Contributor

Thus I think we should tie XDG support and dropping .nvim/.nvimrc and discuss whether both XDG support and drop should happen or whether both XDG support and drop should not happen.

Contributor

ZyX-I commented Jun 14, 2014

Thus I think we should tie XDG support and dropping .nvim/.nvimrc and discuss whether both XDG support and drop should happen or whether both XDG support and drop should not happen.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Jun 14, 2014

Member

Only reason is because I like .nvimrc, and XDG is irrelevant to Windows and OS X, and if we merge the Vim support for XDG then we get everything for "free" (except the maintenance cost).

But you're right about symlinks, and it's better to have one recommended path instead of two.

If one wants to have it there there are shell aliases, variables like VIMINIT (perhaps should be renamed to NVIMINIT), MYVIMRC (did we drop support for it? MYNVIMRC and MYVIMRC seem not to work)

Ok. I'm not sure about renaming those, nor VIMRUNTIME. Need to think about that, because that could affect legacy plugins.

Member

justinmk commented Jun 14, 2014

Only reason is because I like .nvimrc, and XDG is irrelevant to Windows and OS X, and if we merge the Vim support for XDG then we get everything for "free" (except the maintenance cost).

But you're right about symlinks, and it's better to have one recommended path instead of two.

If one wants to have it there there are shell aliases, variables like VIMINIT (perhaps should be renamed to NVIMINIT), MYVIMRC (did we drop support for it? MYNVIMRC and MYVIMRC seem not to work)

Ok. I'm not sure about renaming those, nor VIMRUNTIME. Need to think about that, because that could affect legacy plugins.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jun 14, 2014

Contributor

While XDG is irrelevant for windows using $XDG_CONFIG_HOME/nvim/{…,startup.vim} means that only special-cased (underscore or vimfiles) name at the start of the path component may only be present in $XDG_CONFIG_HOME default. Anybody knows an established convention for $XDG_* locations on windows? I think it is %APPDATA% for configs and data and %TEMP% for runtime and caches.

Contributor

ZyX-I commented Jun 14, 2014

While XDG is irrelevant for windows using $XDG_CONFIG_HOME/nvim/{…,startup.vim} means that only special-cased (underscore or vimfiles) name at the start of the path component may only be present in $XDG_CONFIG_HOME default. Anybody knows an established convention for $XDG_* locations on windows? I think it is %APPDATA% for configs and data and %TEMP% for runtime and caches.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jun 14, 2014

Contributor

Update2:

  • Renamed neovim to nvim as it is new convention.
  • Moved &directory, &backupdir and &undodir defaults to $XDG_DATA_HOME.
  • Made &undodir use trailing // as well.
  • Removed ~/tmp/$TEMP/etc defaults from &backupdir (backups in %TEMP%?!).
  • Removed current directory from &undodir default. If &backupdir was supporting trailing // I would happily remove current directory from there as well: nobody likes spamming working directory with files that are needed only by vim and hardly ever by user.
Contributor

ZyX-I commented Jun 14, 2014

Update2:

  • Renamed neovim to nvim as it is new convention.
  • Moved &directory, &backupdir and &undodir defaults to $XDG_DATA_HOME.
  • Made &undodir use trailing // as well.
  • Removed ~/tmp/$TEMP/etc defaults from &backupdir (backups in %TEMP%?!).
  • Removed current directory from &undodir default. If &backupdir was supporting trailing // I would happily remove current directory from there as well: nobody likes spamming working directory with files that are needed only by vim and hardly ever by user.

@justinmk justinmk added this to the first release milestone Jun 14, 2014

@justinmk justinmk reopened this Jun 14, 2014

@justinmk justinmk removed the reopen-later label Jun 14, 2014

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Jun 14, 2014

Member

Re-opened and set for first-release milestone, because we need to decide this before the first release.

Member

justinmk commented Jun 14, 2014

Re-opened and set for first-release milestone, because we need to decide this before the first release.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jun 14, 2014

Contributor

Update3: All options sharing the same $XDG_DATA_HOME/nvim directory were supplied with distinct subpaths.

Contributor

ZyX-I commented Jun 14, 2014

Update3: All options sharing the same $XDG_DATA_HOME/nvim directory were supplied with distinct subpaths.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jun 14, 2014

Contributor

Added OS defaults and notes:

OS defaults:

  1. On nix operating systems default XDG_ variables according XDG base directory specification.
  2. On windows default XDG_CONFIG_HOME and XDG_DATA_HOME to %APPDATA%, XDG_CACHE_HOME and XDG_RUNTIME_DIR to %TEMP% (just in case) and XDG_CONFIG_DIRS to empty (as VIMRUNTIME is handled separately).

Some other notes:

  1. In any case respect existing values on any operating system.
  2. Entry separator is a colon on any system. It is expected that path separator is a forward slash inside these variables on systems where path separator is a colon.
  3. On startup absent environment variables (only XDG_CONFIG_HOME and XDG_DATA_HOME) should be set to their default values for use in scripts. Code that sets default options this will not have to handle this on its own.
  4. On startup invalid values (XDG base directory specification says that paths must be absolute, relative paths are to be ignored) are replaced with default ones.
  5. Code that sets those variables should live in src/nvim/os/env.c, alongside with restored init_homedir (which currently lives in misc1.c and lacks code for Windows).

. Changes are rather subjectable, please comment.

Contributor

ZyX-I commented Jun 14, 2014

Added OS defaults and notes:

OS defaults:

  1. On nix operating systems default XDG_ variables according XDG base directory specification.
  2. On windows default XDG_CONFIG_HOME and XDG_DATA_HOME to %APPDATA%, XDG_CACHE_HOME and XDG_RUNTIME_DIR to %TEMP% (just in case) and XDG_CONFIG_DIRS to empty (as VIMRUNTIME is handled separately).

Some other notes:

  1. In any case respect existing values on any operating system.
  2. Entry separator is a colon on any system. It is expected that path separator is a forward slash inside these variables on systems where path separator is a colon.
  3. On startup absent environment variables (only XDG_CONFIG_HOME and XDG_DATA_HOME) should be set to their default values for use in scripts. Code that sets default options this will not have to handle this on its own.
  4. On startup invalid values (XDG base directory specification says that paths must be absolute, relative paths are to be ignored) are replaced with default ones.
  5. Code that sets those variables should live in src/nvim/os/env.c, alongside with restored init_homedir (which currently lives in misc1.c and lacks code for Windows).

. Changes are rather subjectable, please comment.

@kopischke

This comment has been minimized.

Show comment
Hide comment
@kopischke

kopischke Jun 14, 2014

@ZyX-I seeing my concerns about swap file locations have been addressed, 👍 from me.

XDG is irrelevant to Windows and OS X

@justinmk on OS X, both terminal Vim and MacVim use the *nix defaults for their configuration, which makes supporting the XDG directory spec as relevant to OS X as it is to Linux et al.

kopischke commented Jun 14, 2014

@ZyX-I seeing my concerns about swap file locations have been addressed, 👍 from me.

XDG is irrelevant to Windows and OS X

@justinmk on OS X, both terminal Vim and MacVim use the *nix defaults for their configuration, which makes supporting the XDG directory spec as relevant to OS X as it is to Linux et al.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Jun 18, 2014

Member

Supporting both XDG base directory specification and non-XDG .nvimrc path is like saying “we do not know where you should put your configuration”.

@ZyX-I I am wondering if supporting "XDG only" will be annoying for users who store their dotfiles in a git repo shared on Windows/Mac/Linux. Having to make an "install" script to set up symlinks will be a chore that previously wasn't necessary.

If I understand the XDG spec correctly, this can be avoided by setting XDG_CONFIG_HOME=C:/Users/justinmk, then nvim will look for configuration in C:/Users/justinmk/nvim/. Is this correct?

on OS X, both terminal Vim and MacVim use the *nix defaults for their configuration, which makes supporting the XDG directory spec as relevant to OS X as it is to Linux et al.

@kopischke So we are not considering ~/Library/ as a location? That's fine with me, but I expect it to be challenged.

Member

justinmk commented Jun 18, 2014

Supporting both XDG base directory specification and non-XDG .nvimrc path is like saying “we do not know where you should put your configuration”.

@ZyX-I I am wondering if supporting "XDG only" will be annoying for users who store their dotfiles in a git repo shared on Windows/Mac/Linux. Having to make an "install" script to set up symlinks will be a chore that previously wasn't necessary.

If I understand the XDG spec correctly, this can be avoided by setting XDG_CONFIG_HOME=C:/Users/justinmk, then nvim will look for configuration in C:/Users/justinmk/nvim/. Is this correct?

on OS X, both terminal Vim and MacVim use the *nix defaults for their configuration, which makes supporting the XDG directory spec as relevant to OS X as it is to Linux et al.

@kopischke So we are not considering ~/Library/ as a location? That's fine with me, but I expect it to be challenged.

@tarruda

This comment has been minimized.

Show comment
Hide comment
@tarruda

tarruda Jun 18, 2014

Member

@justinmk I do not like this idea. Vim support will be optional, falling back to old behaviour because Vim cannot drop backwards compatibility. We can make XDG directories the only default variant since we do not have to be compatible with Vim configuration locations.

I'm against dropping support for plain {.,_}nvimrc. Why can't we simply fallback to it when the xdg directory is missing? I fail to see how this would bring any significant maintenance burden to Neovim:

  • Try $XDG_CONFIG_HOME/nvim
  • If missing, replace $XDG_CONFIG_HOME/nvim by $HOME and try again

Am I missing something here?

Member

tarruda commented Jun 18, 2014

@justinmk I do not like this idea. Vim support will be optional, falling back to old behaviour because Vim cannot drop backwards compatibility. We can make XDG directories the only default variant since we do not have to be compatible with Vim configuration locations.

I'm against dropping support for plain {.,_}nvimrc. Why can't we simply fallback to it when the xdg directory is missing? I fail to see how this would bring any significant maintenance burden to Neovim:

  • Try $XDG_CONFIG_HOME/nvim
  • If missing, replace $XDG_CONFIG_HOME/nvim by $HOME and try again

Am I missing something here?

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jun 18, 2014

Contributor

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On June 18, 2014 4:25:37 PM GMT+03:00, "Justin M. Keyes" notifications@github.com wrote:

Supporting both XDG base directory specification and non-XDG .nvimrc
path is like saying “we do not know where you should put your
configuration”.

@ZyX-I I am wondering if supporting "XDG only" will be annoying for
users who store their dotfiles in a git repo shared on
Windows/Mac/Linux. Having to make an "install" script to set up
symlinks will be a chore that previously wasn't necessary.

Ha! How are you going to avoid symlink problem without XDG? Putting $HOME under VCS control will be a huge pain in ass as you need to explicitly ignore everything but config files. I do not know how to use git in "ignore everything, whitelist some directories" mode. I know how to write .hgignore this way, but the solution I know is rather ugly. Better to write Mercurial plugin (maybe there is one though).

And even if you do put $HOME under VCS control there is no symlink problem with .config. If you do not then you have to do symlinking for everything.

If I understand the XDG spec correctly, this can be avoided by setting
XDG_CONFIG_HOME=C:/Users/justinmk, then nvim will store look for
configuration in C:/Users/justinmk/nvim/. Is this correct?

Yes. But nvim is not the only app using $XDG_CONFIG_HOME on windows. I know at least about powerline.

on OS X, both terminal Vim and MacVim use the *nix defaults for their
configuration, which makes supporting the XDG directory spec as
relevant to OS X as it is to Linux et al.

@kopischke So we are not considering ~/Library/ as a location? That's
fine with me, but I expect it to be challenged.


Reply to this email directly or view it on GitHub:
#78 (comment)

-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQJNBAEBCgA3BQJToYlkMBwfMDI7PjIgHTg6PjswOSAQOzU6QTA9NEA+MjhHIDxr
cC1wYXZAeWFuZGV4LnJ1PgAKCRBu+P2/AXZZImtaD/9ZOU9xBJNcco4kO2pXORli
yiNETWEUyqZTRfPZErMO7TA+e3MHVQNI0IWJVpW9fh7MovcEpwUA+Dmp2jsS7ugt
nrXofeUSasYs18+0JTcUmW9w2xDIRCs2G2zkV/KHVhMnvdjGmDv4OuTP1yCgMydl
Vw70NP4I0YD3Dci66VrGAGuCeEXzgQJBXCirkO9OquphddOxTcu8bz6p2hBwMb0I
P/OILvceOjUDAgJx7f7052aJCLHOr9g4eo/+pbugQxSmyaCXL2hG7VqFLNeU5FRw
+hE0GYsOkEbDv27e2fHRXG9/FZukN+rCdVBoCfcRMLGjdbL/xHG8x0083g+/8+OJ
6mZKUB5ED/vTWnWoaUQ1hu8nP5TWfI68NijeX9Y7Z8EiUw0Q6U6nMSowBITB40dc
ZI+6u2NojhXs+3COzreZyk2dEZQYYC3LoU/YQulzqydifdAL41Cg2MoWBGmM/jx7
sfg4TpQndVud9vmue8aDddNKJ5RYzCsIzaz3R+bYqkbzVDkCjbUyjNGSWJhLT9IX
M1TZ1r33nvgWmIeSxkvFG1fTzjmhsXy3WeJPGi11NE5upzvaGoe1qmadmFE0x1vv
9z7xr/0Pik9DhFtW+azwPk3vQVvTBiZFrF1UT4TLfDA0jeMoVxp6o+3SbU3/uEqj
neIg+1OX55ehLdVR3yJazA==
=artV
-----END PGP SIGNATURE-----

Contributor

ZyX-I commented Jun 18, 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On June 18, 2014 4:25:37 PM GMT+03:00, "Justin M. Keyes" notifications@github.com wrote:

Supporting both XDG base directory specification and non-XDG .nvimrc
path is like saying “we do not know where you should put your
configuration”.

@ZyX-I I am wondering if supporting "XDG only" will be annoying for
users who store their dotfiles in a git repo shared on
Windows/Mac/Linux. Having to make an "install" script to set up
symlinks will be a chore that previously wasn't necessary.

Ha! How are you going to avoid symlink problem without XDG? Putting $HOME under VCS control will be a huge pain in ass as you need to explicitly ignore everything but config files. I do not know how to use git in "ignore everything, whitelist some directories" mode. I know how to write .hgignore this way, but the solution I know is rather ugly. Better to write Mercurial plugin (maybe there is one though).

And even if you do put $HOME under VCS control there is no symlink problem with .config. If you do not then you have to do symlinking for everything.

If I understand the XDG spec correctly, this can be avoided by setting
XDG_CONFIG_HOME=C:/Users/justinmk, then nvim will store look for
configuration in C:/Users/justinmk/nvim/. Is this correct?

Yes. But nvim is not the only app using $XDG_CONFIG_HOME on windows. I know at least about powerline.

on OS X, both terminal Vim and MacVim use the *nix defaults for their
configuration, which makes supporting the XDG directory spec as
relevant to OS X as it is to Linux et al.

@kopischke So we are not considering ~/Library/ as a location? That's
fine with me, but I expect it to be challenged.


Reply to this email directly or view it on GitHub:
#78 (comment)

-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQJNBAEBCgA3BQJToYlkMBwfMDI7PjIgHTg6PjswOSAQOzU6QTA9NEA+MjhHIDxr
cC1wYXZAeWFuZGV4LnJ1PgAKCRBu+P2/AXZZImtaD/9ZOU9xBJNcco4kO2pXORli
yiNETWEUyqZTRfPZErMO7TA+e3MHVQNI0IWJVpW9fh7MovcEpwUA+Dmp2jsS7ugt
nrXofeUSasYs18+0JTcUmW9w2xDIRCs2G2zkV/KHVhMnvdjGmDv4OuTP1yCgMydl
Vw70NP4I0YD3Dci66VrGAGuCeEXzgQJBXCirkO9OquphddOxTcu8bz6p2hBwMb0I
P/OILvceOjUDAgJx7f7052aJCLHOr9g4eo/+pbugQxSmyaCXL2hG7VqFLNeU5FRw
+hE0GYsOkEbDv27e2fHRXG9/FZukN+rCdVBoCfcRMLGjdbL/xHG8x0083g+/8+OJ
6mZKUB5ED/vTWnWoaUQ1hu8nP5TWfI68NijeX9Y7Z8EiUw0Q6U6nMSowBITB40dc
ZI+6u2NojhXs+3COzreZyk2dEZQYYC3LoU/YQulzqydifdAL41Cg2MoWBGmM/jx7
sfg4TpQndVud9vmue8aDddNKJ5RYzCsIzaz3R+bYqkbzVDkCjbUyjNGSWJhLT9IX
M1TZ1r33nvgWmIeSxkvFG1fTzjmhsXy3WeJPGi11NE5upzvaGoe1qmadmFE0x1vv
9z7xr/0Pik9DhFtW+azwPk3vQVvTBiZFrF1UT4TLfDA0jeMoVxp6o+3SbU3/uEqj
neIg+1OX55ehLdVR3yJazA==
=artV
-----END PGP SIGNATURE-----

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Jun 18, 2014

Member

startup.vim should be taken from the first directory in &runtimepath where it was found

I suggest init.vim: it analogous with emacs init.el, and "startup" is not a convention I have seen anywhere else.

If &backupdir was supporting trailing // I would happily remove current directory from there as well: nobody likes spamming working directory with files that are needed only by vim and hardly ever by user.

Is this a feature we should consider adding?

On startup invalid values (XDG base directory specification says that paths must be absolute, relative paths are to be ignored) are replaced with default ones.

Will ~ be expanded correctly on Windows? If not, this is potentially another platform-specific chore that previously was not necessary.

renamings: vim74 to 7.4, vimfiles to site-contrib, .vimrc to startup.vim. Reasoning behind this: to avoid duplicating data. We already know this directory contains files for neovim since it is named /usr/share/neovim,

Agreed that using context (/foo/bar/nvim) means name doesn't need to be repeated for identifiers in that context. But site-contrib does not convey any relevant meaning, perhaps we should name it runtime.

Changes are rather subjectable, please comment.

All other details look good to me.

Member

justinmk commented Jun 18, 2014

startup.vim should be taken from the first directory in &runtimepath where it was found

I suggest init.vim: it analogous with emacs init.el, and "startup" is not a convention I have seen anywhere else.

If &backupdir was supporting trailing // I would happily remove current directory from there as well: nobody likes spamming working directory with files that are needed only by vim and hardly ever by user.

Is this a feature we should consider adding?

On startup invalid values (XDG base directory specification says that paths must be absolute, relative paths are to be ignored) are replaced with default ones.

Will ~ be expanded correctly on Windows? If not, this is potentially another platform-specific chore that previously was not necessary.

renamings: vim74 to 7.4, vimfiles to site-contrib, .vimrc to startup.vim. Reasoning behind this: to avoid duplicating data. We already know this directory contains files for neovim since it is named /usr/share/neovim,

Agreed that using context (/foo/bar/nvim) means name doesn't need to be repeated for identifiers in that context. But site-contrib does not convey any relevant meaning, perhaps we should name it runtime.

Changes are rather subjectable, please comment.

All other details look good to me.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jun 18, 2014

Contributor

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On June 18, 2014 4:40:02 PM GMT+03:00, Thiago de Arruda notifications@github.com wrote:

@justinmk I do not like this idea. Vim support will be optional,
falling back to old behaviour because Vim cannot drop backwards
compatibility. We can make XDG directories the only default variant
since we do not have to be compatible with Vim configuration locations.

I'm against dropping support for plain {.,_}nvimrc. Why can't we
simply fallback to it when the xdg directory is missing? I fail to see
how this would bring any significant maintenance burden to Neovim:

  • Try $XDG_CONFIG_HOME/nvim
  • If missing, replace $XDG_CONFIG_HOME/nvim by $HOME and try again

Am I missing something here?


Reply to this email directly or view it on GitHub:
#78 (comment)

You are missing an explanation: why. I explained why I do not like this solution and it is not only "maintenance burden". You must be consistent: you either support dotfiles, XDG or history (Neovim specific config with Vim fallback like Vim does with .exrc: all of .nvimrc, .(g)vimrc, .exrc). Supporting two from the list makes no sense. If you absolutely have to omit using XDG directories there are ways to do so.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQJNBAEBCgA3BQJToYrRMBwfMDI7PjIgHTg6PjswOSAQOzU6QTA9NEA+MjhHIDxr
cC1wYXZAeWFuZGV4LnJ1PgAKCRBu+P2/AXZZIncCD/4ypNAp1D2MKARroWbDmRto
z5l47Zf/WbnYppxiLnE8cz9NkDYIWRkiOGSq2ixojmL+uwhGEEEkXxaV6acVKV4A
yeE4neXMTMPHTZSmpiMXJVWZkPlRYTA2E/YShx5yEE6n1gXa2dyfytt0MQAbuYwr
hsAHvFFL5LPPFPSme9uJZHIE5DlsPf2fRLc5+NbGSV8VzHrF96pgcyNXsQtU/S5i
31xw0TnySzbAOqYEZKRHxjo1lp0P4kyKMQiS2xhFBY1D7EBbbsMzOEbbWQPXkDUW
IUUZ9wLSRQxJ8/m993hyqC0gddujj1MjJu03osjuRaEfz6luAzgveClXFaxC8LBn
MNJ0GhFH1sWyEr1fxsX78ZQ+cvP3i9/udux1yrESv8kLwJlv9Pn+1Mn/3jaI3Fc9
GE8FKNC6L+uHwCsa6bwdZeXFhxNIevNusQ7/EmbD7MafaXPsl+av2bIq8+63TYtu
zQ5UiyloQXEKML16h+ComwAxK8El8Yz/MtLy7SsaKGQT1wAqDtegOeSCJeo1072k
0Su52qF7/keumNXP9DevZwZUR8ss/2VMDNzhFgxA0Z//uedkRXkP96pNi+0q2CBP
kI9xZtRTTaaR8Plp/SLrRFqBXI+pJ0hoRUPbFs2LXZH5tEejqDxAZ00MnJ2u2DPL
0PHKrfFnOynh+vXBO2vAew==
=cBZu
-----END PGP SIGNATURE-----

Contributor

ZyX-I commented Jun 18, 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On June 18, 2014 4:40:02 PM GMT+03:00, Thiago de Arruda notifications@github.com wrote:

@justinmk I do not like this idea. Vim support will be optional,
falling back to old behaviour because Vim cannot drop backwards
compatibility. We can make XDG directories the only default variant
since we do not have to be compatible with Vim configuration locations.

I'm against dropping support for plain {.,_}nvimrc. Why can't we
simply fallback to it when the xdg directory is missing? I fail to see
how this would bring any significant maintenance burden to Neovim:

  • Try $XDG_CONFIG_HOME/nvim
  • If missing, replace $XDG_CONFIG_HOME/nvim by $HOME and try again

Am I missing something here?


Reply to this email directly or view it on GitHub:
#78 (comment)

You are missing an explanation: why. I explained why I do not like this solution and it is not only "maintenance burden". You must be consistent: you either support dotfiles, XDG or history (Neovim specific config with Vim fallback like Vim does with .exrc: all of .nvimrc, .(g)vimrc, .exrc). Supporting two from the list makes no sense. If you absolutely have to omit using XDG directories there are ways to do so.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQJNBAEBCgA3BQJToYrRMBwfMDI7PjIgHTg6PjswOSAQOzU6QTA9NEA+MjhHIDxr
cC1wYXZAeWFuZGV4LnJ1PgAKCRBu+P2/AXZZIncCD/4ypNAp1D2MKARroWbDmRto
z5l47Zf/WbnYppxiLnE8cz9NkDYIWRkiOGSq2ixojmL+uwhGEEEkXxaV6acVKV4A
yeE4neXMTMPHTZSmpiMXJVWZkPlRYTA2E/YShx5yEE6n1gXa2dyfytt0MQAbuYwr
hsAHvFFL5LPPFPSme9uJZHIE5DlsPf2fRLc5+NbGSV8VzHrF96pgcyNXsQtU/S5i
31xw0TnySzbAOqYEZKRHxjo1lp0P4kyKMQiS2xhFBY1D7EBbbsMzOEbbWQPXkDUW
IUUZ9wLSRQxJ8/m993hyqC0gddujj1MjJu03osjuRaEfz6luAzgveClXFaxC8LBn
MNJ0GhFH1sWyEr1fxsX78ZQ+cvP3i9/udux1yrESv8kLwJlv9Pn+1Mn/3jaI3Fc9
GE8FKNC6L+uHwCsa6bwdZeXFhxNIevNusQ7/EmbD7MafaXPsl+av2bIq8+63TYtu
zQ5UiyloQXEKML16h+ComwAxK8El8Yz/MtLy7SsaKGQT1wAqDtegOeSCJeo1072k
0Su52qF7/keumNXP9DevZwZUR8ss/2VMDNzhFgxA0Z//uedkRXkP96pNi+0q2CBP
kI9xZtRTTaaR8Plp/SLrRFqBXI+pJ0hoRUPbFs2LXZH5tEejqDxAZ00MnJ2u2DPL
0PHKrfFnOynh+vXBO2vAew==
=cBZu
-----END PGP SIGNATURE-----

@bfredl

This comment has been minimized.

Show comment
Hide comment
@bfredl

bfredl Jul 7, 2015

Member

Lots of people might start using nvim after the first public release and we would be stuck with unnecessary backward compatibility baggage for a while.

Remember that the question of "backwards compatibility", in the cases where it is relevant, also includes compatibility with vim. No matter if/when we do this in 0.1 or 0.2 or later, someone moving (or trying out) vim 7.4 -> nvim 0.1 -> nvim 0.2 -> ... will experience the breaking change somewhere ( if it ends up being breaking)

Member

bfredl commented Jul 7, 2015

Lots of people might start using nvim after the first public release and we would be stuck with unnecessary backward compatibility baggage for a while.

Remember that the question of "backwards compatibility", in the cases where it is relevant, also includes compatibility with vim. No matter if/when we do this in 0.1 or 0.2 or later, someone moving (or trying out) vim 7.4 -> nvim 0.1 -> nvim 0.2 -> ... will experience the breaking change somewhere ( if it ends up being breaking)

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Jul 7, 2015

Member

the code already written and waiting for a PR ala Yamakaky/neovim@f372e5b?

Does that meet all of the criteria specified in the top post of this issue?#78 (comment)

changing the default location of a config file won't require a particularly large amount of code.

Even changing the default 'encoding' had surprising corner cases. I'm speechless that anyone would hop onto a thread and just offer unsupported opinions like this.

Member

justinmk commented Jul 7, 2015

the code already written and waiting for a PR ala Yamakaky/neovim@f372e5b?

Does that meet all of the criteria specified in the top post of this issue?#78 (comment)

changing the default location of a config file won't require a particularly large amount of code.

Even changing the default 'encoding' had surprising corner cases. I'm speechless that anyone would hop onto a thread and just offer unsupported opinions like this.

@mrak

This comment has been minimized.

Show comment
Hide comment
@mrak

mrak Jul 8, 2015

I, too, would like to see something like this implemented as early as possible, while not intending that it hold back a release.

Neovim has had so much hard work and great improvements made that I'd love to see get more traction with a public release. I'm a huge proponent of the XDG style of file organization, but I can content myself with using VIMINIT and some nvimrc settings to emulate the behavior for now.

mrak commented Jul 8, 2015

I, too, would like to see something like this implemented as early as possible, while not intending that it hold back a release.

Neovim has had so much hard work and great improvements made that I'd love to see get more traction with a public release. I'm a huge proponent of the XDG style of file organization, but I can content myself with using VIMINIT and some nvimrc settings to emulate the behavior for now.

@Yamakaky

This comment has been minimized.

Show comment
Hide comment
@Yamakaky

Yamakaky Jul 8, 2015

Contributor

My code isn't waiting for a PR, I was waiting for #2578 to be merged. I will restart my changes from scratch, including this #2578.

Contributor

Yamakaky commented Jul 8, 2015

My code isn't waiting for a PR, I was waiting for #2578 to be merged. I will restart my changes from scratch, including this #2578.

@Yamakaky

This comment has been minimized.

Show comment
Hide comment
@Yamakaky
Contributor

Yamakaky commented Jul 8, 2015

@jck

This comment has been minimized.

Show comment
Hide comment
@jck

jck Jul 31, 2015

Contributor

@Yamakaky can you create the PR now?

Contributor

jck commented Jul 31, 2015

@Yamakaky can you create the PR now?

@Yamakaky

This comment has been minimized.

Show comment
Hide comment
@Yamakaky

Yamakaky Jul 31, 2015

Contributor

Yes, sorry. With the holidays, I forgot.

Contributor

Yamakaky commented Jul 31, 2015

Yes, sorry. With the holidays, I forgot.

@Yamakaky

This comment has been minimized.

Show comment
Hide comment
@Yamakaky

Yamakaky Jul 31, 2015

Contributor

Done : #3120

Contributor

Yamakaky commented Jul 31, 2015

Done : #3120

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Aug 1, 2015

Contributor

Updated 1.i suggestion.

Contributor

ZyX-I commented Aug 1, 2015

Updated 1.i suggestion.

@Yamakaky

This comment has been minimized.

Show comment
Hide comment
@Yamakaky

Yamakaky Aug 1, 2015

Contributor

Why not execute init.vim in &runtimepath in reverse order ? Currently, SYS_VIMRC_FILE then the first USR_VIMRC_FILE* found are executed. Executind all the init.vim in &runtimepath would be more flexible.

Contributor

Yamakaky commented Aug 1, 2015

Why not execute init.vim in &runtimepath in reverse order ? Currently, SYS_VIMRC_FILE then the first USR_VIMRC_FILE* found are executed. Executind all the init.vim in &runtimepath would be more flexible.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Aug 1, 2015

Contributor

Yes, this is logical. Problem is that init.vim usually modifies &runtimepath (e.g. by pathogen#infect, vam#ActivateAddons or by directly modifying &runtimepath), so executing all of them is not doable.

Contributor

ZyX-I commented Aug 1, 2015

Yes, this is logical. Problem is that init.vim usually modifies &runtimepath (e.g. by pathogen#infect, vam#ActivateAddons or by directly modifying &runtimepath), so executing all of them is not doable.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Aug 2, 2015

Member

@ZyX-I 1.ii mentions ~/.config/nvim/startup.vim, should it be ~/.config/nvim/init.vim ?

Member

justinmk commented Aug 2, 2015

@ZyX-I 1.ii mentions ~/.config/nvim/startup.vim, should it be ~/.config/nvim/init.vim ?

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Aug 2, 2015

Contributor

@justinmk Yes, it should.

Contributor

ZyX-I commented Aug 2, 2015

@justinmk Yes, it should.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Oct 17, 2015

Contributor

Added ShaDa file location. Strange, but I did not mentioned viminfo before.

Contributor

ZyX-I commented Oct 17, 2015

Added ShaDa file location. Strange, but I did not mentioned viminfo before.

ZyX-I added a commit to ZyX-I/neovim that referenced this issue Oct 17, 2015

option,main: Partial support of XDG base directory specification
- Add functions that are able to query XDG.
- Replace defaults for
  - &runtimepath. Does not follow #78.
  - &viewdir.
  - &undodir.
  - &directory.
  - &backupdir. Does not follow #78.
  - vimrc location.
- Remove user vimrc file line from :version message.
@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Oct 17, 2015

Contributor

Update 8: Updated init.vim search path, as discussed in some of the PRs.

Contributor

ZyX-I commented Oct 17, 2015

Update 8: Updated init.vim search path, as discussed in some of the PRs.

ZyX-I added a commit to ZyX-I/neovim that referenced this issue Oct 23, 2015

option,main: Partial support of XDG base directory specification
- Add functions that are able to query XDG.
- Replace defaults for
  - &runtimepath. Does not follow #78.
  - &viewdir.
  - &undodir.
  - &directory.
  - &backupdir. Does not follow #78.
  - vimrc location.
- Remove user vimrc file line from :version message.

@justinmk justinmk closed this Oct 26, 2015

sts10 added a commit to sts10/homebrew-neovim that referenced this issue Oct 28, 2015

Change symlink targets
Change symlink targets to point to the new location of Neovim's config files. I think the change was fairly recent, as per [this Reddit thread](https://www.reddit.com/r/neovim/comments/3qgsza/psa_if_neovim_stopped_loading_your_nvimrc_after/), which points to a [issue #78](neovim/neovim#78).

sts10 added a commit to sts10/homebrew-neovim that referenced this issue Oct 28, 2015

Update symlink targets
Change symlink targets to point to the new location of Neovim's config files. I think the change was fairly recent, as per [this Reddit thread](https://www.reddit.com/r/neovim/comments/3qgsza/psa_if_neovim_stopped_loading_your_nvimrc_after/), which points to [issue #78](neovim/neovim#78).

agrimaldi added a commit to agrimaldi/nvim-config that referenced this issue Oct 29, 2015

mgraczyk added a commit to mgraczyk/neovim that referenced this issue Nov 2, 2015

option,main: Partial support of XDG base directory specification
- Add functions that are able to query XDG.
- Replace defaults for
  - &runtimepath. Does not follow #78.
  - &viewdir.
  - &undodir.
  - &directory.
  - &backupdir. Does not follow #78.
  - vimrc location.
- Remove user vimrc file line from :version message.

dwb pushed a commit to dwb/neovim that referenced this issue Feb 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment