[Opinion] Oni2 should target vim users more than VSCode users

[danielo515]

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:

• VSCode users: not appealing
• vim users: Very appealing

Some vim, and lots of VSCode features:

• VSCode users: not appealing (they can have this with a vim plugin)
• vim users: not appealing, they want all vim 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.

[bryphe]

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, viml plugins / configuration, etc). There is a segment of hardcore-vim-users-that-never-leave-the-terminal - it'd be tough to win them over!

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).

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.

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:

• https://github.com/onivim/oni2/issues/592 - Support vim-style tabs
• https://github.com/onivim/oni2/issues/150 - vimrc / init.vim / vim plugin support
• https://github.com/onivim/oni2/issues/528 - vim-style keyboard navigation
• https://github.com/onivim/oni2/issues/464 - command line history
• https://github.com/onivim/oni2/issues/301 - (Q support)

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: , so it's been our focus.

+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:

1) Aside from the issues called out above - what sort of functionality are we missing for Vim users? Is it mostly config / vimrc / init.vim support (ie #150) - or others too? We should be tracking / prioritizing these.

2) Are there features that we have today that would exclude or prevent functionality you'd want from Vim? We should look at those scenarios.

3) Are there specific plugins we should track? We should add them to a list here

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!

[DanielPower]

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.

1. Syntax Highlighting. This may change in the future with the upcoming tree-sitter parser for Neovim, but as it stands, syntax highlighting in Vim and Neovim cannot compare to the syntax highlighting in VS Code, particularly for Javascript and Typescript. Code is read much more often than it is edited, and strong syntax highlighting allows me to more quickly understand and reason about the code I'm looking at. The fact that Onivim2 uses the same syntax highlighting as VS Code is a huge deal to me.
2. A side-by-side diff viewer and editor. This may of course be possible in Vim as well with plugins, but I haven't gotten there yet. I spend a lot of my time in VS Code's diff editor. And it's something that I'd struggle to live without at this point.
3. GitLens. This partially ties in with point number 2, but GitLens is the one VS Code extension that I hold above all others. To be able to quickly compare between two branches (good for reviewing pull requests), search commits, see the commit history of a given file, etc.

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.

[Spirarel]

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,

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.

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.

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.

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.

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.

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.

[giltho]

Hi, A lot has been said that I agree on, but I thought I'd give my point of view as a VSCode user.

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. However :

• Switching to Vim is a LOT of work at the beginning. And I feel like I need a push/help. (This is the same reason is still code on a french keyboard instead of qwerty...). As soon as I heard about oni2, I thought (and still think) this is the help I need (and also, paying for it is my very tiny way of contributing the development of the fantastic work done in ReasonML framework/tooling, e.g. Revery).
• VSCode still has a lot of features that are trivial to use and extremely powerful, and for which I don't see the use for keyboard-only workflow. And Oni2 comes with it.

So my comment is mainly about this

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.

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.

[danielo515]

Wow, I wasn't expected so friendly and good feedback about this, but I'm positively surprised. As others has stated, SCM integration of VSC is awesome. It is probably the only thing that makes me pop a VSCode instance when I have to navigate the GIT history of a file. I also use it when I have to try some new language and I don't want to spend one hour configuring vim, so I just open VSCode and install the plugin. Those are the killer features of VSCode for me.

About Vim, the things I don't want to leave behind are:

• My key bindings. I wrote them all on a separate file that I just include in my init.vim, so being able to just use that on Oni2 will be an instant win
• FzF commands that pops on a floating window. It's awesome, it's comfortable and it's fast. When I need to find some file that I knew that I opened b, bum, a list of all my buffers with preview. When I'm looking for a line on an open buffer, the same story. It's awesome how much mental overhead it saves by just having to remember small portions of what you want and narrow the search. The fact that it appears on a floating window really helps keeping the edit session clean
• wich-key has been a really cool feature. It is a VIM version of what powers space-macs, and I will be very happy to see something similar on Oni2
• vim way or handling tabs and windows. I see it as a great advantage over regular tab-based edition
• VSCode snippet syntax is cluttered and uncomfortable to write. It will be awesome if vim snippet syntax could be used instead.

My .dotfiles are publicly available, so I will add them to the provided list. Thanks to all the answers also!

[Raikiri]

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.

[TimothyKrell]

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.

[CrossR]

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 https://github.com/onivim/oni2/issues/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.

[janvanveldhuizen]

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. But more important, the command window does overlay big parts of the text in the editor. It would be great if onivim would have an option to move the command line back to the bottom of the window.

[tpict]

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.

[kyleshevlin]

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.

[tpict]

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.

[jamischarles]

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

1. Very easy to change keyboard mappings and avoid conflicts (I've remapped SO SO SO much). (doesn't seem to be there yet)
2. Easy integration with linters, and syntaxes, and ctags etc (all the plugin ecosystem from VS Code)
3. Very very fast (that's why I use nvim on the terminal. It's so snappy).
4. I never want to write VIML ever ever again but want somewhat feature parity.

Less important but nice to have

1. Let me customize the status bar (and other parts of the UI) (doesn't have to be via .vimrc, but should be easy)
2. Support for onivim-only plugins that take full advantage of it's hybrid model
3. Support a few of the very popular vim-only plugins... (or get a very close alternative)

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).

Neovim in the terminal

[janvanveldhuizen]

But @jamischarles .... if you are happy and fluent with neovim... why making the switch to oni?

[jamischarles]

@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:

1. Writing VIML isn't too bad if you're just doing key remapping, but as soon as you use it for plugin config, or more complicated use cases it stops being fun REALLY quick.

   Anything from adding custom commands, to installing extra plugins, to modifying look & feel, to looking up conflicting key bindings is just too painful. I've been using it for 5 years now. It was fun to tinker early on, but now I'm too tired to spend a long time whenever I want to change something simple.

2. Language support via autocomplete, snippets, linters etc is too painful. You can spend a few hours getting eslint, language autocomplete, and prettier working just right. But then later something breaks, or you want to tweak it, and you're likely looking at a few more hours.

3. It's too finicky. I use gitGutter to show the sign column for changes. It worked great for a while. Now it doesn't refresh properly, or after I switched laptops, the sign BG was gray instead of transparent. I wanted to display the current path when I switched files, and when I enter the new file. For the life of me I couldn't figure out how to do that on entering without having to press enter (annoying). I lost another several hours to trying to figure that out.

4. It fights me too often. Whenever I install a plugin I always have a few minutes of scratching my head and figuring out why the plugin doesn't work the way I expect it to. Then I have to dig through the plugin code to see how I can manually run the command and rebind it, as well as disabling the bindings the plugin sets up. Sometimes I just end up forking the plugin.

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 vimrc.after) and lose the fickleness and brittleness of keybindings in vim. It can also really really improve on plugins and how they are used, modified and keybound (hoping that the VSCode extension way is much better at that, but unsure).

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.

[bryphe]

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:

1) We need to have a full-modal-keyboard navigation for our file explorer and other UI. https://github.com/onivim/oni2/issues/528 This was one of main reasons too for preferring Vim vs. other editors - so it's certainly lacking for me that we don't have it yet. I plan on starting this work next week.

2) Support for VimL settings and keybindings. I'm currently working through some of these and taking note of the vimrcs we have here: https://github.com/onivim/oni2/wiki/VimL-configs Please feel free to add yours! It's interesting the settings / keymaps everyone has, and helps me get a sense of the most important ones to support.

3) Potentially revisit defaults (#2392) - if we did change defaults, we'd make it easy on the welcome screen to go to a code-like experience for users who prefer that. It's a balancing act! In any case - the VSCode extension integration/compatibility would be unchanged.

4) Support for VimL plugins - a clear list of plugins we support (and ex commands/viml constructs we support). My current goal is to support pure-VimL plugins (which should cover plugins like fugitive, surround.vim, targets.vim, etc)

5) A preview experience in quick-open - this is a feature users love about fzf!

6) Some users mention a plugin that shows keymappings (spacemacs/spacevim/which-key) - this is actually something I was thinking, but more in the context of helping-Code-users learn commands. But I think it could be useful for both! I would like to have something like 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:

• A UI for showing registers
• A UI for showing marks
• Quickfix / location list integration
• Support for custom statusline - we could potentially render it 'inside' our statusline

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.

[jamischarles]

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

1. Keybindings not working as expected (listed some of my issues here https://github.com/onivim/oni2/issues/1423#issuecomment-682387936)
2. Bottom window (quickfix / location list etc) that can be used for any terminal command but integrates back to editor file commands. (I could probably overlook this for a bit if 1. was working).

That's it :).

Quick animated gif to show how I extensively I use that bottom window currently Commands I'm using:

• fzf to open any file
• Nerdtree (side window, but wanted to show it anyway)
• Select from open buffers (powered by fzf)
• GitFiles to list modified files and preview (fzf)
• History to show most recent files (fzf)
• BTags to show tags in buffer (fzf)
• CTags to show cTags for project

Very excited for Onivim. Happy to see where it's headed!

[kira-krul]

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

[CrossR]

General questions are welcomed on the Discord linked in the README!

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 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.

[ersinakinci]

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.

[Raikiri]

@earksiinni mate, github is supposed to be a drug-free community

[janvanveldhuizen]

@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 😂 At the other hand, I tend to use Neovim more often these day, as I am working on Linux too half of the time. I like using the same layout and keybindings independent of the OS I am using. (using Linux ssh-based, no gui) I do not know all the Oni2 keybindings by heart, so I finding myself using the mouse all the time in Oni2. So, if there will be a way to apply most of my customizations in init.vim into Oni2, then I will have the best of both worlds. In the meantime I am still a big fan of the project, and promoting it to everyone in my neighborhood who calls me that stupid old-fashioned command line nerd.

[Asheq]

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):

1. The per-pixel smooth scrolling for every imaginable cursor/window movement
2. The full-featured mini-map (neovim GUIs don't even have a scrollbar 🤷‍♂️ )
3. The polish and maintenance of a commercial product

I would be a happy camper even if there was no VSCode plugin support in Onivim2 at all.

[iwikal]

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 tpope/fugitive.vim, but I suspect I would have to change my git workflow if I was using a GUI editor. Closing vim to do git stuff doesn't translate well to oni2. Other than language extensions, debugger support and some kind of git integration, I also just mostly want smooth scrolling and popup hint windows that don't look like ncurses. I've stayed away from doing too much rebinding and scripting because I didn't want to have to unlearn everything every time I have to use a default configuration of vim.

[fredrik-j-lindberg]

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.

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.

[danielo515]

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.

To who are you answering to?

[iwikal]

To who are you answering to?

My question was directed towards Outrun Labs.

[isubasinghe]

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. The killer features for me are:

• Speed
• VSCode Extensions (I hated configuring neovim for hours and hours)

So in my opinion you can target at least some VSCode developers.

As an aside:

• I would love better keyboard support, I don't want to use a mouse when I am using OniVim, I can't seem to navigate tabs with gt

Best of luck! Hope your project succeeds.