You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if you run vroom it tries to invoke vim classic as 'vim', or if you pass the --neovim option it tries to invoke neovim as 'nvim'. This gets annoying in a few ways:
It gets very confused for users who alias vim to neovim on their systems
It gives you no way to override the vim/nvim command to run
In error scenarios it gives really cryptic error output since it can't infer any context about how the target vim instance is supposed to work
It would be nice to generalize that and add inference so that you have more control over which vim executable it's invoking and it can more automagically figure out which options to pass to whichever vim variant it's pointed at.
The text was updated successfully, but these errors were encountered:
I would like to re-word this issue. Something like 'Allow configuration of the path to vim/nvim executable'. And as part of what needs to be done improve on the errors quality.
The root cause for it is not that we don't do things automatically, but that we use a command name instead of a file and don't allow the overwrite.
For a testing framework making automatic choices is arguably less than desirable, as the mistake in configuration may survive unnoticed.
A side note: I don't think aliases matter as much, because we don't use bash, but symlink collisions in path are very much an obvious problem.
Currently if you run vroom it tries to invoke vim classic as 'vim', or if you pass the
--neovim
option it tries to invoke neovim as 'nvim'. This gets annoying in a few ways:It would be nice to generalize that and add inference so that you have more control over which vim executable it's invoking and it can more automagically figure out which options to pass to whichever vim variant it's pointed at.
The text was updated successfully, but these errors were encountered: