feat(vim): Initial ':vimcompatible' setting implementation

[bryphe]

Issue: For users coming from Vim, Onivim's set of defaults are not optimal and there are a bunch of features that may not be desirable. It'd be better to be able to have a quick way to set vim-like defaults, and then opt-in to additional functionality if desired.

Fix: Introduce a vimcompatible setting - this defaults to off, but if :set vimcompatible is run, it will default to using layout-tabs, positioning them on top, and turning off some features like smooth scroll and minimap.

This is much like how Vim exposes the compatible setting for vi-like defaults.

It'll be a work-in-progress to pick the right set of defaults - for example, we might also want to hide the sidebar with vimcompatible. Open to feedback and ideas!

[mabuchner]

In the spirit of #1551 I would prefer, if Onivim behaves more like Vim by default.

I don’t mind the minimap and the smooth scrolling. Those are actually nice additions, which don’t hurt the Vim experience, but especially the buffer / window / tab management is a core Vim feature, which should work right out of the box. This is also something, which other non-Vim based editors can’t deliver and what Onivim should embrace.

We don’t need a VSCode clone with Vim bindings. We need Vim refined with some sugar from other editors.

[CrossR]

We could consider going down the path we looked at with Oni1, where the option is used to gate a notification.

I.e. if its not set, we pop up and ask so that a user who first launches would be asked. Then once you answer and its set to yes/no somewhere, we can just leave you to it, and its easy to change or get the prompt back if you really wanted it for some reason. That makes the default less meaningful since the user is instantly prompted.

There is a balancing act there, the first launch of the app we don't want to set the wrong impression and give the user a bunch of config options, part of the reasoning behind Oni2 is to help avoid some of the awkward/confusing options that Vim has for new users.

We do also want to set the right expectations as the default we choose will most likely be the one most people use I expect, so the expectations that the default sets are important. Some users will expect Code with Vim and some will expect Vim with Code, with different assumptions around that.

This is probably around the right time for that conversation, with vim plugins or config nearer in the pipeline, and depending how we want to deal with them we could end up with different implementations (Auto load config? Prompt about config? Separate config? etcetc), and that could help the decision here as well.

There is also the fact Oni2, whilst only in Alpha and change should be expected by everyone, is in use by people etc, and turning something like this on by default does change the editor in a big way between updates. Not that means we shouldn't do it, but we should consider the options!

I will say, and the above comment I think agrees with this, that some way of specifying "this is what vim compatible means to me" would be nice. So maybe we default it to [tabs, smoothscroll, minimap] but a user who doesn't mind the smooth scroll can remove it and slowly add stuff at their own pace. This does also add a new config option after I've said we don't want a million of them so...take from that what you will.

[bryphe]

Thanks @mabuchner and @CrossR for the feedback, much appreciated!

Ya, one of the most challenging aspects is figuring the right balance (and which side to optimize) - we're in the precarious position of being caught in the middle of Code and Vim. This is a screenshot of a slide I'm getting ready for Vim conf...

But I think it's very valid. We essentially have two options:

1. Start with Vim-style defaults (tab layout), and make it easy to switch to Code style defaults if someone prefers. Could even be a toggle on the Welcome screen. I do like the idea of vim-style defaults for tab layout, but keeping smooth scroll, minimap, etc.

2. Start with Code-style defaults (buffer tabs), and make it relatively easy to switch Vim-style defaults (the idea behind the :set vimcompatible).

We have users coming in from both directions. But I think it's fair, given the overwhelming upvotes for #1551 to consider option 1.

I'll do the following:

• I'll run a twitter poll and see what default is preferred, and whatever the result is, I'll update the defaults. I'll do this early next week - I'm a bit squeezed for time ATM. Agree that the vim-style tabs are a unique feature, and it's cool to showcase those.
• I'll hold off on merging this until we get the results of the poll. Maybe can do away with this, if we just go with option 1.

I.e. if its not set, we pop up and ask so that a user who first launches would be asked. Then once you answer and its set to yes/no somewhere, we can just leave you to it, and its easy to change or get the prompt back if you really wanted it for some reason. That makes the default less meaningful since the user is instantly prompted.

Yep, I like this idea - in either option 1 or option 2, we can make it easy to toggle on the welcome screen.

Let me know if you have other ideas / feedback.

[yunti]

Personal preference would definitely for me would be a vim default, but I don't think that's the right one, even if you may have more users voting for it (initially at least). I think users that have never experienced vim would find the vim defaults very confusing, whereas it's unlikely a vim user would find a vscode/standard editor default confusing. Together with an obvious way to switch to a vim default on the welcome screen (as you suggested) is probably the route that would provide the best overall user experience. (Probably a good thing to test and see though)

[mabuchner]

As a developer I would clearly not add a vimcompatible option and would instead completely take out the non-layout tab solution. Having to support both layout strategies is a maintenance burden and makes future improvements (e.g. session management) more difficult.

I don't see a problem with an editor called "Onivim 2" behaving like Vim and I would see Onivim 2 much closer to Vim, than to VSCode in the Editor Spectrum.

Even, if Onivim 2 would behave more like VSCode by default, naive VSCode users will get annoyed as soon as they try to edit a file. That's why I would try to keep it simple and not consider those users for now.

Additionally, if Onivim 2 behaves more like Vim, you can refer to all the existing Vim tutorials out there and you don't have to write your own.

[mabuchner]

I also think, the better approach to onboard VSCode users is to give them some help on how to use a Vim-like editor (spacemacs/spacevim/which-key) and to make some Vim features accessible via a GUI.

In the long run this will help all new users and keeps the Onivim 2 architecture more focused.

[yunti]

I always thought for vscode style users they would start with (and permanetly be in) a pseudo insert mode, with something like esc disabled so they just stay in that mode, like a normal editor.
Although a lot of us love the vim part, there us probably a lot of non-vim style users who would just like a really fast vscode (particularly the start up time which enables use-cases that vscode just can't).

[mabuchner]

I always thought for vscode style users they would start with (and permanetly be in) a pseudo insert mode, with something like esc disabled so they just stay in that mode, like a normal editor.

That's a valid point and I haven't thought about that. If it's actually doable, then it voids my "naive VSCode users will get annoyed as soon as they try to edit a file" argument.