Open Melkor333 opened 6 years ago
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?
Also if I totally got it wrong, please explain :)
@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.
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.
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.
Right now keybindings are defined by:
This leads to problems, like:
I think there could be various possible solutions to this. But SpaceVim solves it by doing three things which may work for Oni too:
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.
My approach would be to split this into 3 parts:
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.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!
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?
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!
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.
@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:
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.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 :)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.
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.
@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.
@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.
@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.
@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.
@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..
@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.
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.
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
.
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:
Currently, I don't intend to develop that, but if someone do, I can try and guide/help with that.
@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?
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
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.
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!
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: