extend :checkhealth to migrate vimrc

[justinmk]

If running interactively, we should:

• create an init.vim automatically
• check if ~/.vimrc exists and offer to import it (or link to it? one or the other, not both--keep it simple)

[wsdjeg]

@justinmk I think it is nice feature, but all the situation should be considered.for me
both~/.vim and ~/.config/nvim are linked to ~/Dotfiles/config/nvim, and in ~/Dotfiles/config/nvim I have two files init.vim and vimrc.
that means I do not use ~/.vimrc,just use ~/.vim/vimrc instead.

[fmoralesc]

I think this should work like this:

1. Check for the existence of the init.vim file. If it doesn't exist:

2. Search for candidate init files: ~/.vimrc, ~/.vim/vimrc, etc. (resolve links)

3. If no candidates are found, create an empty ~/.config/nvim/init.vim file without prompting the user.

4. If candidates are found,

   a. if there is only one candidate, ask the user if he wants to use it.
   b. prompt the user, sorting by modification date, preselecting the most recent and marking it at such in the list (so it is obvious).

Should this be done in viml as a plugin or should it be hardcoded?

[justinmk]

autoload VimL function if MYVIMRC is empty?

[jamessan]

create an init.vim automatically

👎 for creating stuff in the user's home directory when it isn't needed.

check if ~/.vimrc exists and offer to import it (or link to it? one or the other, not both--keep it simple)

👍 for helping migrate existing settings.

[fmoralesc]

@jamessan We can use the chance to implement some of the "softer" defaults in #2676. Creating an empty file would be necessary also if we didn't want to prompt the user every time they run nvim...

[jamessan]

No we wouldn't. Other metadata (e.g., the shada directory) is created that can detect whether the user has run nvim before.

But if it came down to a choice between risking prompting the users multiple times or creating unnecessary content, I would come down on the side of doing nothing. We already have better defaults. I don't see a reason to create files the user may not want just because so many other programs have that disease.

[fmoralesc]

Fair enough ;)

[KillTheMule]

I agree with jamessan.

[mhinz]

Hmm, feels a bit like too much handholding.

Maybe we should rather go for an explicit command like :Intro (following :Tutor) that interactively explains differences, default values etc. between Vim and Neovim. Somewhere during this Intro linking or creating could be offered.

And :Intro could then be mentioned on the intro screen.

Neovim should be usable without hassle for people who just want to quickly edit config files (without having an own init.vim), like so many admins do.

[wsdjeg]

@mhinz nice idea.

[fmoralesc]

We could actually make :Tutor offer to do this and make it actionable, after all we do mention the init file at the end of the default tutorial.

[justinmk]

:checkhealth could be extended to do any steps that requiring prompting or migration.

But if it came down to a choice between risking prompting the users multiple times or creating unnecessary content, I would come down on the side of doing nothing. We already have better defaults. I don't see a reason to create files the user may not want just because so many other programs have that disease.

I emphatically agree with that sentiment, my thinking was that silently creating an empty init.vim is no worse than silently creating a viminfo file. Remember this is only for invocations where nvim is started without any arguments. A benefit is that it allows us to use deterministic language with new users:

• "How do I edit my config?" => :edit $MYVIMRC
• "Where is my config?" => :echo $MYVIMRC

[jamessan]

my thinking was that silently creating an empty init.vim is no worse than silently creating a viminfo file.

An empty init.vim has no added benefit to the user experience (unlike an empty vimrc did with Vim), while a viminfo/shada file is beneficial.

A benefit is that it allows us to use deterministic language with new users

I do see the benefit to this, but for me it's still not enough to create unnecessary content in the user's $HOME. Those commands would have worked fine pre-XDG since there wasn't an intermediate set of directories that may need to be created. In a sense, we've made that aspect of the initial UX worse.

[justinmk]

Those commands would have worked fine pre-XDG since there wasn't an intermediate set of directories that may need to be created. In a sense, we've made that aspect of the initial UX worse.

Isn't that another reason in favor of creating the file by default? To save the user the hassle of bootstrapping that path. :edit $MYVIMRC will work just fine because the stub init.vim will respect XDG_CONFIG_HOME.

[jamessan]

IMO, no, because it perpetuates the misbehavior of programs creating unnecessary files. It's simple enough to document the default location of the init.vim and people can create it if they want (or have it created by :Tutor as @fmoralesc proposed).

[tbodt]

I think that if on startup ~/.vimrc or ~/.vim exists but ~/.config/nvim does not, it should tell the user that the config files have moved and offer to:

• copy the files
• move the files
• create symlinks
• don't ask again

[sammbeller]

From the nvim-from-vim document, the suggestion is to put the following lines in your init.vim

    set runtimepath^=~/.vim runtimepath+=~/.vim/after
    let &packpath = &runtimepath
    source ~/.vimrc

If there is no init.vim and there exists a .vim or .vimrc, why not offer to create an empty init.vim in the default location and also offer to insert the above lines into it?