[RFC] Implementation of Spacemacs/Spacevim Concepts

[Melkor333]

One of the main problem people often have when setting up their vim environment is that different plugins come with different keybindings which are more or less hard to remember and it can be time consuming to configure sane keybindings. When working with different programming languages the best would be to have the same bindings for the same features. Setting this up can be a real pain (or even impossible).

SpaceMacs/SpaceVim tries to solve this by introducing a layer system and key chaining. Together with a keyguide they get mnemonic keybindings which can be looked up while being used. This makes getting into using them very easy. I think the high number of contributors is a good sign that the system works.

It would be very cool if Oni could introduce the same kind of Layers to manage packages of Plugins and keybindings. What do you guys think about this?

For those who don't know how SpaceVim work, here a little introduction:

**Disclaimer: I created this short intro just by myself quickly. It may contain errors and is very incomplete. It just describes the keybinding part of SpaceVim** Almost all features can be accessed by pressing SPC (Space) and then mnemonic keys in a row. For example if I want to open the configuration file of SpaceVim I press the following keys one after another: - SPC opens the core Layer - f -> stands for `File`. All File operations can be accessed from here - v -> stands for `vim`. This is still the core layer providing options for vim files - d -> probably stands for the Spacevim **.d** directory. This opens the default SpaceVim configuration file. This can be remembered very easy. But if I for example forget the last button, I can just press SPCfv and after a second the leader guide will pop up and show me all possible options:  This means instead of pressing d, which opens my custom spacevim config, I can press v to show the current SpaceVim version. The next example includes different layers: I want to insert a lorem ipsum sentense: - SPC -> open _core_ layer - i -> open _Insertion_ layer (this is not a real layer, since multiple Layers are accessible from here, but ignore that for now) - l -> open Lorem Ipsum options which is provided by the _edit_ layer - s -> insert a sentence of lorem Ipsum text If I deactivate the _edit_ layer, I can't insert lorem ipsem text this way anymore. But I could write my own _better_loremipsum_plugin_ and add this to my own _better_edit_layer_ which I can then activate to add better functionality if I wanted... Obviously I would have to set the same keybindings in the layer. But if done right, anyone in the world could just use my new layer and it should work out of the box

[TalAmuyal]

If I understand correctly, SpaceVim is a plug-in that connects to an already installed vim/Neovim. So, I am not sure what is the request. Is it any of the following?

• SpaceVim doesn't work with On on your setup
• Oni's functionality should be mapped to SpaceVim
• Oni should have a GUI for SpaceVim

Also if I totally got it wrong, please explain :)

[CrossR]

@TalAmuyal its to do with bringing over SpaceVim concepts into Oni core. Mainly, having an Oni way of doing SpaceVim style keybinds for both the various Oni specific features, and potentially for Vim plugins etc.

[justinmk]

FWIW the Nvim API function nvim_get_keymap exists to enable "key guide" stuff.

Layers to manage packages

The N/Vim :packadd feature addresses this AFAIK.

[Melkor333]

TL;DR: Just read Actual behaviour and Expected behaviour

@TalAmuyal SpaceVim is a Vim distribution which pretty much changes how you add plugins. And one of the main purposes is having sane and reusable keybindings. It does that by providing layers. If you want to have a plugin, you can add it with a plugin manager OR you can create a new layer/extend an existing layer. In the layer you also define keybindings which will work with all other layers. It messes with your init.vim so when using SpaceVim, you have the folder ~/.SpaceVim.d/ for custom settings and in the newest version you even make your configuration in a init.toml file. So for a plugin it is way too complex. As the title suggests, I want to implement some of the SpaceVim concept into Oni. Mainly because setting up plugins and new keybindings to work together is a timeconsuming task which could be done once instead of individually by everyone when setting it up. So I think the request would be something like predefine keybindings so that they are sane, compatible and the same for every language or create plugin packages which work well together, have sane keybindings and can be plug'n'play. And the SpaceVim approach with layers is just one possible solution.

Actual behaviour

Right now keybindings are defined by:

• neovim
• oni
• plugin developers
• the user

This leads to problems, like:

• keybindings being assigned multiple times and the user needs to manually redefine
• keybindings can be very unnatural
• different plugins use different types of mnemonics -> it's hard to remember keybindings
• having to look up keybindings at various places (spread over all the help pages) leads to not knowing them at all/learning only the most necessary ones

Expected behaviour

I think there could be various possible solutions to this. But SpaceVim solves it by doing three things which may work for Oni too:

• chaining keys. This allows for exponentially more keybindings and makes it easier to make memorizable and compatible keybindings
• packaging plugins into layers and defining keybindings for them to keep similar things together
• defining a skeleton of base key chains so that similar layers are also together (in the first example of my first post, this would be the f, which isn't a layer itself, but all layers/keybinding focussed on a file are there)

So one possible expected behaviour would be (at some point) that when I install Oni, there is a working Plugin/Layer Manager in which I can easily install packages of plugins. These packages are already preconfigured to work perfectly with Oni and with the other packages I am going to install with the same manager. When I want to learn more possible keybindings for one plugin, i just navigate to that layer with the proper keychain and a keyguide will show me other features.

Some more thoughts

My approach would be to split this into 3 parts:

• the first part is the "plugin manager". The Plugin manager should support the layer system out of the box
• the second part is a keybindings skeleton. SpaceVim has a rather inflexible way of doing this. The whole keychain has to be defined for every single keybinding. Since all layers are in one repository, this is probably okay. But it is impossible to change core keybindings (e.g. change the f in my first example in the first post to be a d). I think SpaceVim also doesn't have a real skeleton, it just has a core layer which includes this kind of skeleton in the code. But for Oni I think having a well defined skeleton could work better.
• create layers. depending on the depth of the second part, layers would have to follow more or less standards and could be more ore less flexible. I'm sure we'll find a reasonable amount of guidance to get an awesome out-of-the-box usability while giving the layer creators enough freedom to integrate the plugins with an acceptable effort.

But this is just how I would do it. I don't know how the Oni Plugin Manager is going to look and I'm sure you have a greater understanding of what is possible and what could be useful (I'm not very experienced). I would really like if this becomes an open discussion! And I really don't want to just integrate SpaceVim into Oni, but it's the best solution I found for the problem I described!

It may sound like way too much work to create layers for every plugin. But when I look at how many contributors SpaceVim and SpaceMacs have, I am sure that more and more people would start to contribute and it would have a positive effect on the Oni userbase!

[TalAmuyal]

How about I'll try to setup a brunch with a small PoC, just so we could see a concrete representation of my understanding and your vision as precived by me?

[Melkor333]

Yes please! I'm sorry for being not very good at explaining what I think. A PoC of what you understand would definitively be helpful!

[parkerault]

Are the layers all implemented as third party plugins? I am concerned that anything that radically changes the input model away from vim defaults is going to be highly controversial. I personally would not want this to ship with oni by default.

[Melkor333]

@parkerault Thank you a lot for your comment, this is exactly something I have been waiting for! Initially, I had the same concern, but after a lot of thinking about it I came to the conclusion that it shouldn't be as big as a deal as I (and you) may think:

• First of all it should only add a way to add features to Oni. Normal plugins should still work like if layers wouldn't exist at all! No change to the input model, just an extension
• Secondly, I think layers shouldn't be shipped directly with Oni. A small core to show the users that they exist and how they work would probably make sense tho (a bit like the plugins Oni ships with right now. They are far away from being complete but give a good understanding on how Oni can be used). But in the End Layers should be installed with the Plugin(/Layer) Manager.
• I guess the most important point: No matter how many Layers are installed, they would only occupy one key in total (in SpaceVim and SpaceMacs it is the space key) and there should be a way to also deactivate this key! It will never come in your way if you don't want to use it. Btw It changes less vim bindings than Oni itself does right now
• Should they be third party 'plugins'? I think the best way would be one repository which holds all official layers, but an easy way to also install third party layers. SpaceVim does it that way and I think it's the best way to have control and keep stuff compatible/sane. If layers are all third party like plugins, there would probably be no big differences between plugins and layers and I'm a bit concerned that all the effort would be for nothing.
• I know it sounds scary when I say that there would be official and unofficial layers - it sounds like I would throw away all efforts towards user freedom. But when I look at the user base of SpaceMacs and SpaceVim it seems like a lot of people choose this 'restraint' over the time consuming but more individual way of configuring everything themselves. And in the end it would be cool if both user groups would be satisfied :)

[justinmk]

I don't see where :packadd was addressed, which I mentioned above. It also sounds like a ton of work--mostly busy-work, not anything fundamental, which will be thrown away the next time someone wants to invent yet another "distribution".

spacevim exists, so why not use it? Many distributions exist. Bringing all of that onto Oni's shoulders will be a quagmire.

It's easy to request, but endless to satisfy. There are 1800 open issues on spacemacs.

I think the best way would be one repository which holds all official layers,.. If layers are all third party like plugins, there would probably be no big differences between plugins and layers

This is why distributions don't work: they centralize maintenance of hundreds of plugins. This doesn't scale. I don't know why people keep attempting it.

[Melkor333]

I'm sorry for not addressing :packadd. This would probably be a good technical solution to the question of how to handle the layers. But my main point is not having the ability to add packages of plugins, it is the whole keybinding thing. (btw. I'm not sure if Oni plugins could also be added with :packadd)

SpaceVim could be used, but it competes with Oni. Right now Spacevim and Oni both include some of the same features in a different way. And I don't think using SpaceVim and having to modify half of the layers is a good solution. Also all the SpaceVim bindings are in the neovim input model, so it wouldn't even be possible to integrate Oni things right away.

Thanks a lot for this interesting article! I didn't read the whole article (yet) since the database stuff becomes a bit too complex for my understanding but I think I got the point. I guess you may be right, it could become a quagmire if we would do one centralized distribution. SpaceVim has way less issues, but I this will probably add up exponentially. So it may not the best way to have one repo. And having them third party is probably equivalent to having no layers at all.

defining a skeleton of base key chains so that similar layers are also together (in the first example of my first post, this would be the f, which isn't a layer itself, but all layers/keybinding focussed on a file are there)

I guess this is the only thing that will be left and it can be done technically in the configuration with something like that (though I don't know if this would become unmaintainable at some point/has some drawbacks):

  let chain_leader = "<space>"
  let oni_layer = chain_leader+"o"

  oni.input.bind(oni_layer+"q", "oni.quit") //<spc>oq to quit oni

Idk if there is any interest in creating default keybinding-"layers" like the oni_layer in the above example. But if this would be done and some basic features like the keyguide would be added, it could probably attract quite some people (again, looking at the appearantly big userbase of spacemacs and spacevim). It could be seen as an additionial convenience layer like described here which doesn't require the effort of maintaining third party plugins.

[parkerault]

@Melkor333 I don't use spacevim, but it sounds like what you are proposing is a major overhaul of core functionality. I would love to see the spacevim input model available for oni users but it's too much to ask of the core maintainers when it's not something that is widely requested. This is something that realistically should only be implemented as a series of plugins. You may be able to get some of the other contributors around here to help out, but if you want to make this happen I would suggest that the best way to approach it is to start developing a prototype as a plugin.

[TalAmuyal]

@Melkor333, just wanted to say that I didn't setup a PoC yet since my hands are full with a previous feature (https://github.com/onivim/oni/pull/2315) Will do the space-PoC as soon as I push this one. @parkerault, you can be sure that I do not intend to degrade either the performance nor the UX in Oni. I think it can be done as a contained plug-in - thus it could be turned off easily.

[wsdjeg]

@Melkor333 @TalAmuyal Hello SpaceVim author here. I do not think these is any thing need to be done in oni, as oni is a GUI of neovim, It should keep TUI compatibility, If SpaceVim works well in tui or any TUI-like gui client ( neovim-qt, gvim etc). It should work well in oni.

oni is an awesome gui client of neovim, it provides many gui elements, and it also provide a tui compatibility mode. just same as using neovim in terminal.

[Piping]

@wsdjeg I totally agree. Oni as an awesome gui client modernizes the user interface and thats already a big plus. For vim-user like me thats works with various people, various server machines and already have a decent vimrc, it is important to not change any default vim key-binding and adding new key-binding should not confuse users as well.

[Melkor333]

@wsdjeg right now there is no big problem in using SpaceVim together with Oni (except that you have to disable many default Oni or SpaceVim features which would be redundant). But one major point is that SpaceVim doesn't integrate with the Oni Input model. So when using SpaceVim with Oni, one has to use the Oni config file, the SpaceVim config file AND for some circumstances a custom init.vim. This is very inconvenient. Not to forget they are all in a different format (typescript, toml and VimL).

Another point is that two goals of Oni are to have a rich plugin development (without VimL) and Modern UX (=no more terminal style visualization with vim statusbar & co. -> the Oni API instead). This means no matter what, there WILL be some "competition" when it comes to plugins. SpaceVim would have to create extra layers just for Oni to fit well into it anyways. And since Oni will have it's own Plugin management, I'm sure it would need quite some work for SpaceVim to get this to work properly. I think it is better if SpaceVim focusses on staying the best (neo)vim distribution instead, while Oni copies some of SpaceVims ideas for it's own plugins, input management, etc.

@Piping check the answer I gave to parkerault, he mentioned the same thing.

At first glance it seems counterintuitive to use a new concept like the one SpaceVim uses with its keychaining. But for new users, I'm pretty sure the spacevim-style is less confusing than the default keybindings (especially due to the possibility to have a very clear keyguide). Of course we have to consider that the ability to use multiple ways is confusing itself, since new users don't know how to decide which way to use. But there are multiple possible ways to guide the new user through this (spacevim-style just deactivated by default, the ability to activate/deactivate spacevimstyle upon startup with a short comment, etc.).

But let's wait for @TalAmuyal to implement a PoC. I think right now everyone has a slightly different understanding of what this RFC/Feature Request should be. I think the PoC will bring some clearance into this..

[Piping]

@Melkor333 @wsdjeg I totally agree that VIM's key binding is not obvious at all. I need to read a book to understand how to use VIM, but most new users would not do that. Vim lacks the guidance for new users. Even with above said, I like vim's way editing. Once I know how to do things in vim's way, I can apply my knowledge to different server machines, different text editors and also works with different people. SpaceVim does not provide that at all. And the text editing experience is efficient and open minded.

One thing I really like about Oni is the tutorial section. I want to contribute to Oni so that vim's way of editing will be obvious for new users, with proper UI feedback and response. It takes me about 3 days to master the vim style. But I believe it benefits me for whole life.

[Melkor333]

Actually I don't think VIM bindings should necessarily be implemented in a spacevim way. I'm more going for additional plugins like the language server.

Spacevim does implement commands to e.g. switch windows/buffers the spacevim way and it makes sense because then it is consistent. But I myself prefer the vim commands for such tasks and since there are tutorials for those things I think it would not make sense to create additional commands for them.

[wsdjeg]

Spacevim does implement commands to e.g. switch windows/buffers the spacevim way and it makes sense because then it is consistent. But I myself prefer the vim commands for such tasks and since there are tutorials for those things I think it would not make sense to create additional commands for them.

any thing need to be done in SpaceVim? as I know in SpaceVim, you can also use the old vim key binding, for example <C-w>h/j/k/l.

[TalAmuyal]

Tried SpaceVim for a bit and it seems fine with Oni.

BTW, after trying SpaceVim on Oni I was left a bit confused as to what should be done on the Oni side.

I can think of the following options:

1. Wrap SpaceVim in a custom UI (should be doable by reading SpaceVim's files to get the command-tree).
2. Add an Oni layer or hook up Oni commands as any other plug-in that is supported by SpaceVim.
3. A combination of the above.

Currently, I don't intend to develop that, but if someone do, I can try and guide/help with that.

[Melkor333]

@wsdjeg it was only an answer to the opinion that SpaceVim concept would "dramatically change the input model" which is definitifely not my goal...

@TalAmuyal thanks a lot for taking your time to look into it!!! :hearts:

And sorry but my understanding of "Oni layer in SpaceVim" was a bit limited until I read your comment, I never really thought about controlling the Oni config in SpaceVim :see_no_evil:

So yeah I think it would make sense to do a combination of both - creating an Oni layer in SpaceVim and creating a wrapper for the SpaceVim UI (I think as an Oni plugin?). And I would love to do this, but since I'm not really experienced any help is greatly appreciated!

@wsdjeg if you don't mind I would start to work on an Oni layer as soon as I get some time? And when this works out I can start with an Oni Wrapper Plugin?

[danielpza]

Has any work been done in this area?, I come from spacemacs so don't know much about vim config and how to combine spacevim and oni together, could someone point me in the right direction ?, maybe it could be in the readme

[wsdjeg]

I will add a oni layer in SpaceVim，and It will only provide tui compatible function. with this layer you can use spacevim in oni just like in terminal.

---

Shidong Wang

-------- 原始邮件 -------- 主题：Re: [onivim/oni] [RFC] Implementation of Spacemacs/Spacevim Concepts (#2322) 发件人：Daniel Perez Alvarez 收件人：onivim/oni 抄送：Wang Shidong ,Mention

Has any work been done in this area?, I come from spacemacs so don't know much about vim config and how to combine spacevim and oni together, could someone point me in the right direction ?, maybe it could be in the readme

― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/onivim/oni/issues/2322#issuecomment-448459079, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMiJkmTXcAFHIOJlLl-kPVrItfstEnZBks5u6bU8gaJpZM4UpdTD.

[Melkor333]

I'm really sorry I got very much going on in my life since mid August and couldn't really do anything... Thanks @wsdjeg for looking into it!