Oni: Alternate Distribution

[badosu]

From what I see the 0.3.2 release will have tutorials and achievements enabled by default.

I think that's great for newcomers but terrible for regular users, ideally that would be opt-in IMO.

So, to not scare away potential users migrating to Oni I am thinking of creating a distribution for Oni with the minimalistic settings, the only difference is that a config.js with these settings will be loaded before the user's own settings.

To achieve that I have some ideas:

• Be able to load a config.js file apart from the default location (e.g. /etc/oni/config.js)
• After loading that particular file, load and override with the user's settings.

This does not address the concerns I have with the direction that is being taken, as this will probably just be available for Arch users at the moment, but is a good mitigation strategy (I would not like users moving away from Oni after this change, a new package will be created for vanilla Oni).

[CrossR]

I quite like the idea that @bryphe had in that we can offer up a custom config.js as part of the initial startup procedure, similar to #1942.

That way, a new user can opt out on initial start up. The worry there is that they could miss it, so perhaps we could also have some form of top level config option? i.e. One config option that disables everything in one go, to make opting out easier. This would also help in the future as when a new feature is added, it could be enabled by default for everyone, except those who have opted out. Thinking about it, a custom config file fails there, since in the next version if something new is enabled, they need to manually add it.

Again there though the worry is that somebody wants Oni as close to vim as possible except one specific thing, so we'd have to have an easy way to opt back in again, and also a comprehensive list that tells the user all that has been disabled, so they can opt back in easily. It also would be hiding things potentially the user would want, if they knew it existed.

[badosu]

I think having a better onboarding experience would be great! So the user could say if they want the opinionated (beginner friendly) defaults or just the minimal settings with a predefined and adjustable config.

If that is done before 0.3.2 I think that would suffice.

The suggestions I pointed out are orthogonal and would provide a way for alternate distros, so I think that would be still worth it.

[bryphe]

Thanks @badosu for your thoughts around this! I'm glad you keep a balance here to make sure we don't alienate existing Vim users.

Agree 100% with a better on-boarding experience. It is painful for a user to have to go and update a bunch of configuration values to get the minimal experience, even though we have that nice config maintained on our wiki. To be honest, originally, I did not expect very many 'purist' Vim users to use Oni - I assumed that the technology choice alone would alienate them. But I was wrong about this andd there is some subset that would like a slightly more modern experience - and there's no technical reason we can't make it easier to expose a more minimal config. And I definitely understand that not all users will appreciate the tutorial or achievements experience - it can be challenging to appeal to both audiences (trying to bring new users into Vim, and handling the power Vim user's case).

The first thing I'd like to do is check-in that minimal Vim config, and ensue that we have an automation test that covers it. This helps because as we update it (or add new features, and disable in the config), we have confidence that the minimal config will always work.

And then I'm thinking about the following ideas:

1. Expose a oni.minimal setting. If this setting is true, we will use that minimal Vim config as the 'base' config, so we'd use those defaults unless explicitly overridden by the user. It's at least simpler than having to maintain a bunch of other configuration settings.

2. Have a way in the __Command Palette__ to quickly change this setting, without needing to jump to a configuration file:
   
   Selecting that item would set oni.minimal and reload Oni. If oni.minimal is set, we'd expose an opposite setting, like: Configuration: Switch to Full. Not sure the best names for those settings, but just a brainstorm..

3. Have a first-time setup experience - here's a quick, basic, ugly mock-up of what I'm thinking:
   

This would also be a natural place to surface an init.vim option (if we detect the user has one), or potentially address #1730 and have an option to consent to telemetry. And obviously all the text / etc would need to be tweaked.

Just some thoughts... we could do any combination of those if they make sense. Let me know what you think @badosu @CrossR @Akin909 .

@badosu - the good news is I think it makes sense to take this for our next release. The bad news is that unfortunately I won't be able to squeeze this in for 0.3.2. But I think your proposal to have a separate distro in the meantime is OK (the suggestions for alternative default configs seem useful in any case).

LMK what you think, if that would help address this. It's not necessarily ideal to have to prompt this on first run, but I think it can be a clean way to help users get the experience they want out of Oni - whether that is a full-on augmentation or a minimal wrapper around Vim, and it keeps the user from having to dig into a config file to get that experience. It's at least a one-time cost.

It also means that we can better serve the "pro user, minimal vim" scenario - when we add new features, that won't have to keep opting-out as they do today - we can respect that oni.minimal setting and they would be insulated from new features, unless they decide to opt-in.

[justinmk]

Related to this, I've been thinking that Oni could make sense as the flagship Nvim GUI. A minimal mode would really help there.

[bryphe]

@justinmk - thats really cool (and an honor to even be considered for that 👍 ).

In that context, it could make sense to have what @badosu mentioned initially - separate builds / distributions. An Oni-full and an Oni-minimal. The Oni-minimal would have our minimal config (externalized features like tabline, etc turned on by default, so we can highlight the capabilities of Neovim, but not include stuff like tutorials/achievements/etc). We'd just to have to figure out the right set of functionality to include there - @badosu 's minimal config is a great starting point.

Tangentially related to this... my plan is eventually to factor out some of the functionality that is 'core' today in browser/src/Services to oni (npm) plugins, ie:

• oni-plugin-quick-open
• oni-plugin-command-palette
• oni-plugin-language-services
• oni-plugin-key-displayer
• oni-plugin-textmate-highlighting
• oni-plugin-learning
• oni-plugin-sidebar-search
• oni-plugin-sidebar-explorer
  etc...

We don't have a robust story for oni-plugins at the moment, which is a blocker to doing this today - but I'm looking at putting that foundation in place as the next step of our roadmap. Once we have that story in place, we could refactor those out incrementally... and the Oni-minimal could conceivably just be Oni. The Oni-full distribution would become Oni + a set of the above plugins installed.

[justinmk]

separate builds / distributions. An Oni-full and an Oni-minimal

I'm wary of different "versions" just to save a few MB (thinking of maintenance cost + user support/confusion). "Minimal" with ability to opt-in to "full" would be fine.

and the Oni-minimal could conceivably just be Oni. The Oni-full distribution would become Oni + a set of the above plugins installed.

That would certainly be ideal!

[badosu]

That's good to hear!

We are using the terminology minimal, but frankly this is actually covering the essentials for the vim frontend we never had, and I am excited about it!

With regard to the distribution discussion, we need a mechanism to load the configuration without all the extras but adjustable in a way that the user can transition smoothly to optin the features they desire, a way to load a config by filename that can be overriden by the user would achieve that. My proposal would be a flag to load a file by base name present on oni's config directory (the config directory list can be prepended by other directories, e.g. /etc/oni for better packaging and avoiding conflict with the user's own settings). E.g. oni -c minimal traverses the config directories for minimal.config.js with the user's directory on precedence.

With regard to making Oni a flagship GUI for Neovim, I think by restricting and prioritizing the scope for the essential features for a basic frontend we would make sure that it works as expected and a surefire decision for vim users and also establish a solid foundation over which the full blown IDE can grow.

What I have in mind is an editor that behaves exactly as vim from the get go, users should feel that they are in the same environment as their trusty old vim (being a thin frontend), with a lot of added extras that really make the difference to stay with it (a handy file explorer, markdown preview, LSP interoperability with good UI, etc...), all of these which are discovered progressively with grace.

The first step would be to make sure that the essentials are covered though: no font rendering issues, smooth scrolling seems to be a big deal, no unexpected behaviour on insert mode like snippets, automatic autocomplete popup, autopairs, etc.. So that the user facing features are rock-solid, which hopefully should be easier with a reduced surface area.

Configuration should be really straightforward so that the user progressively discovers and enables the features that really make a difference. With experience we will discover from scratch what are the features that are turned on by almost everyone and set them as default by demand.