[Opinion] Oni2 should target vim users more than VSCode users #1551
Comments
|
Thanks for your thoughts and feedback, @danielo515 ! Really appreciate it. Striking the right balance between VSCode-level IDE functionality and Vim experience has been a challenge since our first version! It's something we're continually thinking about it - and the major driving factor is feedback from our users. So discussions / feedback like this helps a lot. Our niche, at the moment, is really users that are stuck bouncing in between the two worlds - I'd like to be able to broaden that in both directions (to bring VSCode users over - make the editor more approachable and easier to learn. To bring Vim users over - support Vim configuration, Given that we have a full Vim implementation backing Onivim - we have a lot of flexibility in terms of how we leverage it and implement features. Biggest challenge is that, since we're a small team with limited resources, we have to aggressively prioritize (and again - feedback helps with that).
Totally understandable! Given that one of our main goals is compatibility with VSCode extensions (and it is a lot of work to get there - and has been our focus for multiple months)... and we still haven't implemented several of the Vim-compatibility pieces we are targeting (the milestone for it has been pushed back), I can see why you'd have that impression. Some of the compatibility issues we are tracking:
We don't have a perfect prioritization system, we use the GitHub reactions a lot to help us prioritize - ie, the extension host work is way at the top: +1 'ing on issues (make sure to '+1' the issue itself, since the comments aren't tracked in our queries) that are relevant helps us prioritize - so I encourage everyone to '+1' / 👍 issues that are relevant to them, and if we're not tracking an issue - we should be, so that we can prioritize it! I think a good next step would to be dive down to the next level, into more specifics, and:
Also, one other thing that can help - if your vim config files available, and you're willing to share them - please add them to the list here: https://github.com/onivim/oni2/wiki/VimL-configs#viml-configurations-initvim-vimrc-etc Again, I really appreciate the thoughts and feedback, we want to build a great product for our niche! |
|
I'm currently a VS Code user. Before that I was a Sublime Text user, and an Atom user before that. But I've since started learning Vim (Neovim more specifically), and the power of modal editing, repeatable actions, and macros. I've now come to love Vim's modal editing, but there are a few specific things that have held me back from fully embracing it.
I've tried to use vim extensions for VS Code, but their quality is just not great. The most popular one is just called Vim, and it is slow, and has many conflicts between its keybindings and the VS Code keybindings. As well, it has issues with its undo/redo history conflicting with VS Code's undo/redo history, because the actions are not equivalent. I've also tried the extension called Neo Vim, which has better performance, and actually uses your local neovim binary to handle actions, and even supports plugins, excommands, etc. But it's new, unfinished, and seems to have halted development. Most unfortunately, it doesn't work in the side-by-side diff view. So to me, OniVim2 is already quite close to being the best of both worlds. The things holding it back for me right now are mainly the various bugs, and the lack of diff views and git integration. Other than bugfixes and some ui polish, if OniVim2 were to get to a point where it could run the GitLens extension, I'd essentially be done looking for an editor. |
|
I appreciate reading this point of view and I'm glad you shared it @danielo515. That said, I do find myself in a different camp. First,
This is, sadly, not the case. Vim emulation for VSC is hamstrung by a very coarse API. The team behind Vscodevim has a done a great job despite this, but coming from (neo)vim/Atom, leaves a lot to desire in terms of modal editing. If VSC had Atom's vim-mode-plus, then the value proposition (to me) of Onivim would be much smaller. But it doesn't and the maintainers of VSC are reluctant to expose parts of the editor code that would make the experience more comparable.
Seeing as how there is already a split between adherents who use GUI vim and (by my impression) many more who are dedicated terminal vim users, I don't see this happening. Especially when 100% VimL compatibility is a non-goal of the project.
If this is what you're after you might be interested in gui vim. Last I checked it has some attractive features like smooth scroll and better font support. You won't have VSC-like features though (debugger, extensions manager, well integrated terminal, SCM, refactoring, etc.). That or Spacemacs. It's worth mentioning that any project needs supporters i.e. users and VSC rightfully owns a huge share of the editor market—it's very capable and it's slick. Onivim's best value prop is to present a truly modal take on editing that is similarly featureful and beautiful. |
|
Hi, I have started programming a lot only in the last few years, so I haven't been educated to vim/emacs at all. I've done some python through python-only editors, some OCaml in the "ocamltop" GUI if you can believe it. I've done some Java in Eclipse, and some C in Codeblock. As you can imagine this was mostly for school assignments and we often did not have the choice because it was on school machines. My first actual editor was Atom, and I switched to VSCode when it became obvious that it overpowered Atom. A lot of people around me use Vim/Emacs and I can certainly see the advantages.
So my comment is mainly about this
I am a VSCode only user that wants to take advantage of the modal power + native performances, and I think Oni2 is the perfect project for this. |
|
Wow, I wasn't expected so friendly and good feedback about this, but I'm positively surprised. About Vim, the things I don't want to leave behind are:
My .dotfiles are publicly available, so I will add them to the provided list. |
|
VSCode's vim emulation is terribly slow. Unusably slow for me. Getting vim to a point of being as usable as VSCode is, takes more time than I want to spend on it. I think I fit the current onivim2's target audience pretty well and I'd like it to stay exactly where it is. |
|
I've backed OniVim and am really excited about it. My biggest fear is that I will lose some of the keyboard-driven power of some of the plugins I use in neovim currently. The biggest of these are nerdtree and fugitive. No matter how much I try, I have never felt as productive in VSCode with it's file browser or any of the git plugins. Some of the git plugins have great features, but I can't drive them 100% from the keyboard. With fugitive I can stage, commit, amend, and diff lightning fast because everything is a keystroke away. Same with Nerdtree. I can browse and take actions on files without ever leaving the home row. If OniVim 2 isn't going to support extensions like nerdtree and fugitive, I would really like the built-in solutions to be built with home-row, keyboard-driven operation first and not tacked on as an afterthought. |
We have #528 open for the explorer bindings, but we do want in general everything to be keyboard accessible so that you can use the explorer and the source control with the keyboard, and then later stuff like a debugger or browse extensions (they are just quick examples from the top of my head). The broad version is that we want the best bits from vim or the best bits from VSCode, or when it makes sense the hybrid of the two, like all of the modern UI of Code but with the keyboard friendly UI with vim bindings. |
|
I find myself falling back to vim or nvim more often. The fullscreen text mode just feels more comfortable. More 'vim', so to say. The :cd and :ed commands in nvim are a lot quicker for navigation, than using the mouse in the file explorer treeview. |
|
One of my favourite things about Vim is that I can use a window to hold a buffer, a terminal, a file explorer, Git explorer, command output etc, and have consistent keyboard behaviour between each of them. I'm not at all familiar with Onivim's internals, but I think what would be more valuable than specific key bindings for different panes/features is the ability to focus these things as if they were a regular window, and interact with them as if they were a regular buffer... just like Vim. I'm sure this is a little alien to people use other editors, and as "modern UX" is one of the goals of Onivim it could fairly be relegated to an opt-in feature. Still, it's worth stressing that all the Vim emulators I've given up on in the past have failed when it comes to UI management, and not necessarily at text editing. |
|
I'll be straight up and honest, Onivim doesn't get my $40 if it wasn't very VSCode like. I want to get into modal editing and the efficiency benefits without having to figure out how to setup an IDE in my terminal with a bunch of vim plugins and stuff. I've tried before, it's just more pain than using VSCode and makes me give up every time. Call me a quitter if you want, but I'm just telling you why I was willing to pay money for the license. I wouldn't give a dollar if this was just meant to be "nicer vim" in the terminal. |
|
That's completely fair–there already are dozens of "nicer Vims" which haven't really taken off, probably because they don't provide any benefit that outweighs the cost of moving away from upstream Vim/Neovim. If I were to reduce the scope of "target Vim users more" to something more actionable, it would be this: Vim's UI being freely manipulable and scriptable using the modal paradigm is as much a benefit as its modal text editing, and it's always jarring to use software that does the latter but not the former. A lot of the gripes in this thread are a subset of that problem: I can't place window X at position Y, I can't replicate plugin Z etc. I don't think that modern UX is incompatible with Vim's UI flexibility any more than the nice editing features we have (floating hints, minimap, smooth scrolling etc) are incompatible with modal editing. |
|
Wanted to add my 2 cents real quick. I've used Frontpage, Dreamweaver, Textmate, Coda, Sublime, Atom, VS Code, then a Vim GUI and now for the last several years Neovim. I use Colemak for my keyboard layout and have spent HOURS upon hours modifying my vimrc file. I've since gone extremely minimalistic with my vim setup. Coming into Onivim mostly blind (I just bought a copy today) here's what I'm hoping for... My must haves
Less important but nice to have
I think I'm ok with losing some of the VIM things I like, but it'd be amazing to support some of the really popular ones like FZF for filesearch (or even just a sliding window that we can fully control with commands like fzf) and a file tree that is fully keyboard usable. Frankly, for me the perfect balance would be if I could 1) get all the custom keymapping and modal support (I'd love to be able to map leader keys like double space to go to most recent buffer etc) 2) FAST and 3) great integration with the VSCode ecosystem (while staying fast).
|
|
But @jamischarles .... if you are happy and fluent with neovim... why making the switch to oni? |
|
@janvanveldhuizen I didn't say I was happy with neovim 😃. I use neovim because it's currently the best option for the things I care about. These are the things that I cannot stand about neovim, that Onivim can undoubtedly improve on:
In summary, I'm now at the place in life where I want to spend my limited time hacking on more important things than my editor that's 98% does exactly what I want but is fighting me for the last 2%. I think that's where onivim can really shine. It can improve on keybinding (so I don't have to place things in weird orders, or in weird files like In short, the only things I really want to keep from neovim are 1) Speed 2) Flexibility for movement around my code 3) Flexibility to add custom behavior (but make it easier. If that means adding my own onivim plugin that is fine). I'm happy to move or trade up on all the hard and painful things. I do want some sort of scripting behavior for more complex modifications but would love something better than VIML. |
|
Just a FYI - I've been quiet but I'm distilling the feedback. I really appreciate the great conversation and all the thoughts here! Some actionable items I've picked out from this:
EDIT: 7) Cluster of command-line / search issues: (history, command line window, etc): #382 #301 #434 #843 #916 #1056 Other top of mind items:
It'll be a busy couple months! 😄 Ultimately I know there are a lot of users have poured a lot of time into their vimrc/init.vim - and I want to do justice to that in this milestone. Would be great if your keybindings, settings, etc - just worked - and additional features like minimap, smoothscroll, etc just fit in seamlessly. Def want to improve this for our current milestone (0.6.0). This is kind of a braindump, but let me know if there is anything I'm missing. |
|
Thank you @bryphe for the transparency. Greatly appreciated and will keep folks like me invested and engaged in the process. I don't want to hog too much airtime so I'll keep this short. 👍 To everything you've said. Want to add / clarify a few things for me: Here's what blocking me from using Onivim for coding right now
That's it :). Quick animated gif to show how I extensively I use that bottom window currently
Very excited for Onivim. Happy to see where it's headed! |
|
Not sure if this is the right place to ask, but is it an option to add vim syntax highlighting on top of existing one? I really think plugins like vim-easymotion or quick-scope that use it should be supported. I use the latter a lot Another option is to make it possible to change colors in oni from vimL. Plugin creators would have extra work to do but if it's easier to implement than it's a good compromise |
|
General questions are welcomed on the Discord linked in the README!
I would guess it is technically possible for us to do this, but right now we get no syntax information from libvim, and we rely on textmate for that instead. That then leads into your second point where all the themes we use are based on the textmate scopes, rather than anything that vim would use, so it would be a lot of work to map together the two worlds, where I'm not sure it would be possible in a clean way. We do then have experimental tree-sitter work (which is what nvim is moving towards as well) which would make the vim syntax HLs less useful as well. There is also semantic HLs via VSCode extensions we could use in the future which achieves something similar to tree-sitter. That isn't to say that we can't use those sorts of plugins, me and @bryphe did speak about easymotion and vim-sneak recently actually, so it is on the radar! For more involved plugins, there is a few options we can take. Custom versions to inform Oni2 about events etc so we can natively render them, or just doing our own version natively in libvim so we can get any and all info we need etc, or just going fully native and adding it to Oni2 itself for example. We could also look at adding Oni2 specific interfaces or Oni2 specific plugins, but hopefully understandably that is lower on the priority list at the moment! Makes more sense to put the work in now to support two very popular plugin ecosystems versus making our own with only a few plugins. |
|
I just bought a copy of Oni2 today, like others coming in more or less blind. I used Neovim + a bajillion plugins for about a year, then switched to VS Code + Vim plugin for the past 6 months. Having switched back and forth between them, I realized that what I've really wanted this whole time is a blazing fast Neovim with a thin layer of native (or native-passing) IDE so that I don't have to set up weird macros for "copying to the clipboard buffer." VS Code + Vim plugin was perfect in terms of functionality, but the performance left much to be desired. Oni2 hits the nail right on the head and keeps driving into the plank of wood until there's nothing left but splinters and a hole in the earth that goes straight to the earth's core. There, you can see the magma that powers our entire planet's biosphere. Beating within the core's center is an orb made from a material known only to three pupils of Albertus Magnus, the famed alchemist. Its exact chemical composition lost to the generations, the orb holds within its inner sanctum a secret sigil so profound that none dare speak its name. Yet a haunting resonance can be heard emanating from the chamber's walls betraying the secret that Magnus and the stars would keep, pulsating with the life force of the entire world: "Oni2, Oni2, Oni2..." I'd say keep the balance where it is, y'all are doing good work. |
|
@earksiinni mate, github is supposed to be a drug-free community |
|
@earksiinni , I share your enthusiasm about Oni2 and I would recommend to @bryphe to use your post on the Oni2 web site to promote the project 😂 |
|
My 2 cents: I just want a "nicer" (neo)vim. What draws me to Onivim2 (that the many neovim GUIs out there don't have):
I would be a happy camper even if there was no VSCode plugin support in Onivim2 at all. |
|
Have you been doing any user surveys to find what people want from their editor, and how they are using VSCode/Vim/whatever today? If so, I've managed to miss them all. Basically all I use VSCode for is their debugger integrations with gdb and node. I use git through the command line, and occasionally I stage things to commit using |
Definitely agree. What I am looking for is pretty much VsCode made with "keyboard-first" mentality. Keyboard navigation in the editor should be intuitive. Not just for the editing of text (where I obviously want modal editing), but for navigating the sidebar & its sections, the terminal and settings etc. without you having to customize workarounds for it by yourself or desperately try to tab your way to the section you want focused. |
To who are you answering to? |
My question was directed towards Outrun Labs. |
__Issue:__ All of our bindings, whether defined by `nmap` or `nnoremap`, were allowing recursive definitions. This breaks the case in #2114, where the remaps would bounce back and forth until they hit our recursion limit. __Defect:__ We weren't gating recursive remaps, aside from the recursion limit. __Fix:__ Define and handle no-recursive remaps correctly. __Todo:__ - [x] Update existing test cases to pick up new API - [x] Add test cases to validate non-recursive maps - [x] Get tests green - [x] Add integration test covering #2114 - [x] Update CHANGES - [x] Rebase on #2883 when merged Fixes #2114 Depends on #2883 Related #1551
__Issue:__ `I` and `A` in visual-block mode should allow inserting, or appending, characters across all linewise selections in the visual block __Fix:__ Implement using our in-progress multi-cursor support:  Functionally, this should behave the same as `<c-v>`+`I`/`A`, but show all insertions during the gesture (as opposed to Vim, which would only show a single insertion, and then propagate them on the `<esc>` press). A baby step towards snippets & multiple cursors Fixes #1633 Related #1551
__Issue:__ There were a couple related issues with the cursor in command-line mode: 1) When exiting command-line mode, the cursor could 'flash' at the top of the file 2) When running a search command, the viewport would not scroll to the first match __Defect:__ Both issues stem from the fact that Onivim was ignoring editor-cursor-position changes during search. For the first issue, when exiting command-line mode, there would be a brief transitional state where the editor is focused in CommandLine mode, but no cursor would be available - so it would be rendered at the default (0,0) position. This would be rectified once the mode transition completed and the cursor position is reset. For the second issue, `libvim` was properly updating the cursor position when searching, but that cursor position was being ignored. __Fix:__ Track the editor cursor position during the course of the command-line interaction Fixes #2968 Related #1551
|
Idk if this will help you. I just want this project to be successful so I thought of adding my thoughts just in case that it may be helpful. I was an IDE user for a long time, IDEs were what I used in high school and in undergrad. I kinda got annoyed with VSCode, it was too slow for me (on a 2020 MacBook Pro), then I swapped to neovim, I do love my neovim setup, its really really fast. I started searching for IDEs that are like VSCode but aren't written in Electron and found OniVim. I still use neovim, but I swap to OniVim when I need a full blown IDE now.
So in my opinion you can target at least some VSCode developers. As an aside:
Best of luck! Hope your project succeeds. |
Hello everybody.
I'm a baker that has a lot of hopes on Oni2. Sorry if this is not the proper place to share an oppinio, but it's the closes place that is not a chat that I found.
After many tries NeoVIM is finally my main code editor, but I still have VSCode open on the background for certain tasks. I would really want to drop VSCode completely, but it has some features that are just impossible to implement in vim.
And here is the bit of opinion. Oni2 seems to target VSCode users that want a vim experience rather than VIM users that want a closer IDE experience. I know that the project motto is exactly the opposite, but my feeling is that you are putting more effort into mimic VSCode features and behavior than on just improving vim.
The reason I think VSCode users should not be the target audience is because... well, they already have a very complete and competent editor and having something similar but with less features except for modal edition is not going to be appealing to them. It's like the uncanny valley. They will see a VSCode like editor with less features and they will give up. If they want modal edit they will probably be more than happy with any of the vim plugins.
Vim users on the other hand, are passionate about vim and they will probably be very happy to have a complete vim editor with some extra VSCode will be something they will really appreciate. Most vim users have already invested countless hours on their configurations, and they will not be leaving vim for something that is not vim complete, but they will appreciate any little improvement over it.
So, to summarize
Full VIM support with some extra IDE features:
Some vim, and lots of VSCode features:
As you can see, there is no good scenario for targeting VSCode users.
For me an ideal scenario for Oni2 will be like the Emacs desktop version of emacs: it is just emacs with some extra things around it on a window.
In any case, this is just an opinion and I really appreciate the work you're doing here! Keep up the good work.
The text was updated successfully, but these errors were encountered: