Improve vimrc loading

[blueyed]

Via #1 (comment) from @tweekmonster:

I was also thinking about removing the requirement of sourcing /rtp.vim and having a standard vimrc script that loads a known script name from the volume instead.

Please elaborate, but I understand it as such there should be another vimrc sourced by a minimal script, which could be /rtp.vim still.

btw: I had some remarks somewhere regarding Neomake to push some things into the default vimrc IIRC.

[tweekmonster]

What I meant is that instead of the user sourcing /rtp.vim in their own script, we could instead setup an environment that just works for both Vim and Neovim. In hindsight, I think it's annoying to impose special setup when Vim has a pretty well defined startup procedure.

How I think it should work:

Volume

The volume directory is /testbed

• The developer's entry script is /testbed/testbed.vim
• Developer can use the testbed.vim's script path to get the directory.
  • Removes the need to hardcode /testbed/ so that the script can be ran without the Docker container.
• testbed.vim would be a dangling file analogous to .travis.yml.

Home directory

The user directory should be /home/testbed instead of the current /home. It has the default directory structure that's compatible with Vim and Neovim:

• $HOME/.vim/init.vim
• $XDG_CONFIG_HOME/nvim -> $HOME/.vim
• $HOME/.vimrc -> $HOME/.vim/init.vim

Startup

The container's $HOME/.vim/init.vim script does the following:

• Prefixes /testbed to runtimepath
• Sources /testbed/testbed.vim

The container ENTRYPOINT script runs exec su -l vimtest -c "env VIM_TESTBED=1 /vim-build/bin/$BIN $ARGS". VIM_TESTBED is a flag that might be useful to non-trivial plugins that call external scripts.

Just a thought: plug.vim could be bundled to aid with fetching dependencies.

Benefits

• The developer doesn't need to know $HOME/.vim/init.vim exists or what it does.
• The developer's scripts don't need to know about the internal structure of the container.
• The $HOME directory structure is at least consistent with a real user's environment.
• No need to have a special setup for Neovim files.

[blueyed]

Makes total sense.

testbed.vim would be a dangling file analogous to .travis.yml.

Can you elaborate what you mean with "dangling" here, please?

I suggest then also to include some default vimrc, e.g. https://github.com/neomake/neomake/blob/master/tests/vim/vimrc (which is based on your's used for braceless).

[blueyed]

The container ENTRYPOINT script runs exec su -l vimtest -c "env VIM_TESTBED=1 /vim-build/bin/$BIN $ARGS".

Shouldn't it still cd /testbed?
Did I understand it correctly that /testbed replaces /testplugin?

I have some WIP here - will create a PR later.