VSCode-Neovim future & request for new developers

[theol0403]

Hello everyone, thank you for using the extension and sorry for the long periods of silence. Here are my thoughts on the project.

History

In 2019, @asvetliakov created this project as a proof of concept. At the time, the neovim API was less mature, and many workarounds and design decisions were made. The project gained popularity, but there was much work left to do (and so much potential!).

Starting in 2020, he has been working on/off, doing a couple major refactorings, being busy for a while, then coming back. However, I don't think he has been very involved since early 2022.

In 2020, I contributed by making some PRs to the docs, vim bindings, etc. I was then given triage permissions to help manage issues. Later, in 2021, I was given full admin. Summer of 2022, I contributed my own features.

I myself have been sporadically contributing, as I am an engineering student at university and only have a few months of the year with free time - and even then, I work full-time and have other hobbies/projects. I contribute when I feel like it, and ignore it for the rest of the time.

@justinmk has been very helpful in providing some high-level guidance, doing some issue triage, and he has the keys to the project in case everyone else disappears.

So, my role in this project is just that I was given the keys, have a decent vision of what the plugin should be, and have the ability to write decent code. However, there is not some special reason why I am in charge today, and I feel like I shouldn't be, considering my commitment to the project.

@asvetliakov created #889, and lots of people added their input, but ultimately no one took over the project (though some people definitely contributed).

Work remaining

This extension has a TON of potential, and can be much better. There are many workarounds/ugly pieces of code that can be removed with new nvim APIs, and many more integrations are theoretically possible.

Specifically, there is a lot of work relating to:

• file model: currently, vscode simply syncs a scratch buffer to nvim, and manually intercepts most of nvims commands (like :e). However, a better and cleaner model involving actually hooking the real nvim commands might be possible.
• sync model: currently, the sync mechanism between vscode and neovim is complicated and brittle. I've already refactored the vscode -> nvim sync, but the other way still needs work. Removal of dot-repeat workaround would be a start.
• visual selection: currently, the visual selection is fake. Syncing it to a real vscode selection is possible and ideal.
• viewport sync: lots of work needs to be done to properly sync the viewport with nvim
• project management: contribution guidelines, better dev environment, automated releases, bug report templates, etc
• fully embrace lua and remove all vimscript
• bug fixes
• missing API integrations (folds, quickfix nav, feature parity with vscodevim, etc), and calling more vscode bindings
• extra features (multi cursor, which key integration, etc)

Additionally, there is a lot of buried ideas/knowledge in the issue trackers, and abandoned code in the git history.

I will write about the state of multiple PRs/features at some point.

The project philosophy should be clean, minimal features. As @justinmk says here: #889 (comment), the focus should be on deleting features, and letting neovim do more of the lifting.

RFC

What do people think would be the best step moving forward? We ideally need a new, dedicated maintainer with the time to make refactors and steer the direction of the project. Perhaps being adopted by nvim? This plugin is, after all, the poster child for neovim's API. Additionally, many issues in this project are being blocked by missing nvim APIs, and higher priority with the nvim devs would definitely speed up development.

Who is prepared to lead this extension, and figure out how to best make it thrive? I think a lot of work needs to be put in to streamline issues, releases, CI, documentation, and facilitate contributions, which will make developers feel more inclined to contribute. I am happy to work with them (and I very well may continue to work on features myself), but I can't avoid the long periods of disengagement.

Maybe add some policy where developers get triage rights with 2+ PRs, and admin rights with 5+ quality PRs?

Looking forward to hearing your thoughts.

[theol0403]

Pinging people involved in the past @justinmk @trkoch @wenfangdu @ctstacey

[justinmk]

What do people think would be the best step moving forward? We ideally need a new, dedicated maintainer with the time to make refactors and steer the direction of the project.

We don't necessarily need the "ideal". Having someone who can:

1. make good judgements on a few mergeable PRs
2. do a release every 3-4 months

is much better than waiting for the ideal. Though certainly the door is open for the ideal case, if anyone steps up.

[theol0403]

@justinmk for sure. However, this is nearly what we have right now (the frequency of merges could be improved), and while we may be getting the occasional bugfix, the project is not moving much at all. Additionally, the project is quite complex, and any significant PRs need more involved maintainers.

I think that with better leadership/management (myself included), we can encourage/facilitate more collaboration, and that starts with getting more contributors.

I think the gist of my post is that I personally feel like my disappearances hold back progress of the project, where maintainers are discouraged from contributing, and no one steps up because they aren't fully aware of the need and don't know the status of the project, and if I abolish myself of responsibility, someone might step up.

However, I am committed to creating a periodic release schedule for small PRs.

[justinmk]

However, I am committed to creating a periodic release schedule for small PRs.

That's very helpful.

[theol0403]

My authentication tokens for publishing are currently broken... may have to contact Alexey if the issue persists.

[wenfangdu]

Perhaps being adopted by nvim?

That would be awesome! NeoVim + VSCode is definitely a win-win situation.

[justinmk]

Being "adopted by Nvim" isn't a magic solution. We still need an owner to drive this.

[Bekaboo]

@theol0403 Thanks for all your contributions to this greate project! One thing I find missing in this pligin is inseart mode mappings, which prevents me from using snippets from Neovim in Vscode. It is even possible that insert-mode mappings will eventually handled by Neovim not VSCode?

[theol0403]

It is even possible that insert-mode mappings will eventually handled by Neovim not VSCode?

No, while certain insert-mode mappings are supported, completions/snippets/lsp will always be something that VSCode will be responsible for (by design).

[Bekaboo]

@theol0403 Thanks for your prompt reply.

[martin-braun]

@Bekaboo You should build yourself the equivalent in VSCode for insert mode. VSCode is more powerful when it comes to LSP stuff, so you want VSCode to handle insert mode exclusively.

[Bekaboo]

@martin-braun Thanks for your suggestion. Actually by saying insert-mode mappings I mean snippets more than LSP stuff. There are much more we can do with insert mode mappings other than completion keymaps, snippets being one of them -- for example I have tons of rather complex latex math snippets built upon LuaSnip that are impossible to replicate using VSCode's LSP-style snippets, which prevents me from writing latex and markdown in VSCode.

I also encounter problems when trying to remap <C-j> instead of <Tab> for accepting inline hints in VSCode natively, after some searching I find it a known bug of VSCode that you cannot remap some keys to accept inline hints in VSCode when the completion menu is present. This is just one of the limitations that I encountered when I try to custom the keymaps in VSCode.

[martin-braun]

@Bekaboo I understand your concern and I understood that this is not about LSP stuff. My point was that insert mode was dedicated to VSCode to handle everything incl. LSPs. For instance, I can't use Codeium for Neovim, I have to use Codeium for VSCode, and Codeium for VSCode is more powerful, so it's good the way it is. If we bridge the insert mode, we lose compatibility and performance on VSCode's side for things like LSP.

Now in your case, you feel the opposite, since your Vim stuff is actually more powerful than VSCode's stuff, because you modified it extensively in a way that VSCode can't keep up. Both worlds have their strengths and weaknesses I suppose.

I also have cases in which I don't want to use VSCode, I simply came up with a hybrid configuration that allows me to have a consistent experience in terminal and VSCode. VSCode drains more battery than a simple terminal. I'd advice to use VSCode only when you benefit from its powerful features. For instance, I picked up this project, because I have to modernize a Flutter project and coc-flutter is too immature to refactor things in a quick pace with proper assistance.

I think a more idealistic approach would be to offer two modes in vscode-neovim, "VSCode Insert Mode" and "Neovim Insert Mode". This would indeed solve your issue as you could bypass the insert mode of VSCode.

However, then I would ask you: Why using VSCode in the first place? nvim-tree and tmux can give you the same benefit. If you dedicate insert mode to Neovim you can pretty much forget 95% of all VSCode extensions, as they couldn't hook into code suggestions and so on and so forth.

Other than that, this project would also become even harder to maintain. I think passing-through insert mode to Neovim is a different level of complexity, as vscode-neovim doesn't even support floating and inactive buffers which are heavily used by suggestion engines in Neovim.

[theol0403]

The furthest that would be technically possible is:

• functional insert-mode bindings/sync where everything is synced immediately and keystrokes are sent directly to nvim
• forwarding nvim completion menu to vscode as a completion provider, and using the vscode completion selector
• intercepting nvim menu selection # and replaying it in vscode?

Basically, you need to use vscode for any ui elements, but it could definitely be coupled more closely with nvim. Too much work/complexity unless some new dev comes along.

[justinmk]

The furthest that would be technically possible is: ...

Those are good ideas, but a counterpoint to implementing them is that it confuses the "messaging" of the project. For example, if Nvim insert-mode completion was supported, people will still just ask for more and ask why other insert-mode things aren't supported.

However, then I would ask you: Why using VSCode in the first place?

This, a million times. Constraints are good. Users need clear messaging so they can decide tradeoffs. "I want all features in all modes to magically cohere perfectly at all times" is a confused situation. If you are using vscode then make the choice to use its features in insert-mode. Else don't use vscode.

[Bekaboo]

@justinmk Thanks for your insights. Why are we always talking about completion when it comes to insert-mode mappings? I would say VSCode completion is as good as, if not better than Neovim's. What is currently missing (in my opinion) is using snippets from Neovim. Sorry if I didn't clarify it before.

[justinmk]

Completion is just an example. VSCode has snippets, not to mention many other insert-mode features.

[martin-braun]

@justinmk If I understand him correctly, snippets in VSCode are too weak for him, compared to his Lua snippets for LuaSnip.

@Bekaboo

Why are we always talking about completion when it comes to insert-mode mappings?

Because snippets require the completion engine in insert mode to work. In my experience, snippets are served like any other code suggestions, so in order to make them work, you have to make suggestion-passthrough to VSCode work, which requires to bridge into insert mode and hook stuff up. This is a ton of work, because there is more than one completion engine.

What is currently missing (in my opinion) is using snippets from Neovim.

LuaSnip has support for VSCode Snippets, but VSCode does not have support for Lua snippets, which I suppose you use. I doubt you can squeeze more out of it.

I think the solution you strive for exceeds the scope of this project, because of the variety of suggestion engines available for Neovim. VSCode has only one suggestion engine, so I think it is rather good to invest into a snipping file format that can be supported in both editors with different plugins/extensions.

Somebody basically has to build a LuaSnip VSCode extension.

[Bekaboo]

@martin-braun Yeah that sounds reasonable.

[theol0403]

I forgot this would work better as a discussion... then this whole insert mode discussion could have been a thread. Transferring