[HN Gopher] VSCode-Neovim: Use embedded Neovim in VSCode without...
___________________________________________________________________
VSCode-Neovim: Use embedded Neovim in VSCode without emulation
Author : satvikpendem
Score : 122 points
Date : 2022-11-22 18:21 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| WesSouza wrote:
| But can I embed VSCode on Neovim? Yeah, didn't think so.
| [deleted]
| jamesappledev wrote:
| That's pretty much what coc.nvim is
| fire wrote:
| My biggest complaint is probably that it doesn't support overlay
| or popup windows, which makes it impossible to use plugins like
| WhichKey[0] and such, which I like on normal neovim because I'm a
| scrub and don't know vim hotkeys by heart
|
| 0: https://github.com/folke/which-key.nvim
| dbalatero wrote:
| I don't use VSCode, but if you use this plugin or the other Vim
| plugin for VSCode, make sure to put it in its own thread so it
| doesn't compete with other blocking tasks and slow down your
| editor motions.
|
| See "Affinity" docs here for putting it in its own thread:
| https://github.com/vscode-neovim/vscode-neovim#installation
| asabla wrote:
| Oh snap! Been more and more annoyed lately about just this.
| Thank you for sharing!
| satvikpendem wrote:
| This must be a new option, hadn't seen it before. Thanks!
| dbalatero wrote:
| It's new within the last year for sure! It's also marked
| "experimental" and I think therefore not heavily advertised,
| but IMO it's also necessary for something like Vim motions
| that need to move at the speed with which you type...
| pacomerh wrote:
| To me the greatness of using something like neovim/vim is that
| you don't have to use the mouse. This I don't know what's good
| for...
| satvikpendem wrote:
| Good for people who like the ergonomics of VSCode (one-click
| plugin installs, everything simply "just works" out of the box)
| with the ergonomics of Vim (modal editing, speed).
| dbalatero wrote:
| This. I'll go to VSCode from Neovim kicking and screaming,
| but frankly VSCode + a good Vim plugin is the pragmatic
| choice for most people out there looking for a Vim-like
| editor.
| stu2b50 wrote:
| The advantage of Vim is efficiency and speed. The disadvantage
| is that it has a longer learning curve.
|
| For something like editing text, as a programmer you do this
| endlessly - it is absolutely worth it to be ruthlessly
| efficient at this, even if you have to pay effort learning it.
|
| But for, say, installing a plugin in your text editor... that's
| something you do a handful of times a month. The mouse is much
| more adaptable and easy to use, even if you give up accuracy.
|
| This way, you can be efficient at editing text without having
| to learn keybindings for a bunch of misc things that you do
| rarely.
| mewse wrote:
| > The advantage of Vim is efficiency and speed. The
| disadvantage is that it has a longer learning curve.
|
| I'm not disagreeing with this comment all, just throwing my
| anecdata at the somewhat squishy "longer" word in that
| sentence.
|
| For me, I went cold-turkey with vim (my employer wanted me
| coding on both Mac and Windows at more or less
| simultaneously; I figured it would be a useful investment of
| time to learn a single set of hotkeys that I could use on
| both systems and get into my muscle memory, rather than
| trying to keep Xcode hotkeys and Visual Studio hotkeys
| straight in my head)
|
| I stopped using literally any other text editor or IDE either
| at work or at home, just to try to learn vim as fast as
| possible, and spent a bunch of recreational time playing
| VimGolf.
|
| As I'd expected, it was catastrophic for my productivity
| initially, but I reached a basic proficiency within five
| days; I got back to my normal development cadence quickly
| enough that my lead didn't even notice I had taken time to
| teach myself to use a "difficult" text editor; I just had one
| week where I was slightly behind schedule, before catching
| back up and getting ahead during the following week, where my
| skills improved even further.
|
| It definitely _is_ a longer learning curve before you can say
| that you 've "mastered" vim than most other editors. But you
| can reach a basic competence equivalent to other (non-emacs)
| text editors pretty quickly; it's just that there's still a
| lot more useful functionality you can learn after that point.
| dcow wrote:
| I tried this plugin a few years ago. It was neat but ultimately
| buggy and not ironed out enough to use daily. To people who
| currently use it, has it improved noticeably?
| cassepipe wrote:
| Does that mean that I don't have to learn how to use VScode _at
| all_ ?
| vukadinovic wrote:
| I used VIM plugin until now, was happy to see this. However,
| tried installing it on top of neovim 0.9.0-beta and VS code
| complains that the version nees to be 0.5 or higher... switching
| between modes worked but moving (jkli) didn't. So gave up trying
| to install it. Might try later looks interesting
| barefeg wrote:
| I love neovim but I don't have a good replacement for the git
| plugin of vscode. I haven't found my way to replicating that
| experience in neovim. I tried lazygit but I find the diff viewer
| hard to understand and navigate. Diff view
| (https://github.com/sindrets/diffview.nvim) might be it, but I
| haven't made the time to install a newer version of git from
| source (Debian...)
| aussiesnack wrote:
| vim-fugitive is ergonomically great for routine stages and
| commits.
|
| DiffView is good but there's no point denying GUI diff viewers
| are better than text ones, so I use one (meld or sublime-
| merge), which does mean launching a separate tool. That's fine
| for my limited uses (quick visual overviews, or fixing merge
| conflicts).
| minusf wrote:
| have you tried fugitive?
|
| the vimcast videos about it can be life changing.
| christophilus wrote:
| I'm the same. For the most part, I use a nice terminal git diff
| (I forget which-- not in neovim), and I hop around in neovim
| based on what I see there. I do sometimes open Codium just to
| navigate a large diff, and it always makes me a little sad.
| petepete wrote:
| Similarly, I use diff-highlight 99% of the time because it
| works flawlessly with all of git diff's arguments (including
| --word-diff) but break out Meld for big content-heavy
| changes.
|
| https://meldmerge.org/
| CollinEMac wrote:
| I use the regular vim extension in VSCode. How does this compare
| to that?
| sblom wrote:
| This has caused me to realize that I need to replace my old model
| of vi:
|
| > command mode has primacy; insert mode is a time-bounded special
| case
|
| with:
|
| > insert mode is every other mundane editor; use the Esc key to
| enter the matrix (i.e. command mode)
| pacavaca wrote:
| I remember trying neovim with Atom a while ago. At that time I
| realized that me using nvim it's not just about
| motions/plugins/no mouse, etc, but rather the whole terminal
| experience. For example, I rely heavily on tmux for splitting my
| screen whichever way suits the current task best and then, I may
| spontaneously open nvim in some of the splits or run other CLI
| tools. This experience is not the same with the CLI built into
| vscode or any other IDE.
| capableweb wrote:
| Personally, my problem with trying to use Vim keybindings in VS
| Code is not about the motions of moving around/editing the code
| itself, but everything else. You end up in plenty of situations
| where you have to resolve using the mouse because you ended up on
| some sub-page or whatever, where you either need to resolve using
| the mouse or keep pressing Tab until you get to where you want to
| go.
|
| Installing plugins is one good example of this, where even if you
| use a Vim plugin (or this, it seems), you still need to resolve
| to using the mouse/Tabbing to actually install the plugin itself.
|
| While with Neo/Vim itself, you never need to reach for the mouse,
| because the entire thing, not just the editing/writing, is meant
| to facilitate keyboard-only usage.
| coldtea wrote:
| > _Installing plugins is one good example of this, where even
| if you use a Vim plugin (or this, it seems), you still need to
| resolve to using the mouse /Tabbing to actually install the
| plugin itself._
|
| Sounds like a minor annoyance at best... Where vim-mode is
| important to me is editing and navigating code, not when
| installing plugins...
| capableweb wrote:
| As I said, it's one example. Anything outside the code window
| suffers from the same problem, not just installing plugins...
| FeistySkink wrote:
| Not sure if you know, but you can install plugins from
| terminal.
| rendall wrote:
| Ctrl+shift+p puts the cursor in the command search where you
| can find all the commands including extension related commands.
| Ctrl+w j puts the cursor in the terminal.
|
| VS code is entirely navigable with key strokes even with Vim
| emulator
| capableweb wrote:
| As mentioned, extensions is one example. How do you resize
| the sidebar? Or resizing the vertical size of the "Outline"
| pane?
|
| To be honest, guess it was a long time ago I last used VS
| Code, but when I did, I ended up in situations where it
| wasn't suitable to use the keyboard too many times.
| Tyr42 wrote:
| I guess I am the target market. I don't mind using the mouse
| when I'm not in the "flow" of editing. Even browsing code,
| scroll wheels are pretty expressive, and clicking to jump to
| definition is fine. Ok not typing, so I don't need to keep my
| hand on the home row.
|
| But the actual editing doesn't use the mouse.
| Lio wrote:
| It's worth pointing out that while Vim/Neovim can be fully used
| without a mouse you can still use one if you want to.
|
| That includes mouse wheel, clicking tabs, resizing windows,
| balloon help amongst others.
|
| That works over SSH too.
| gabrielgio wrote:
| That is the reason why I moved from eMacs to neovim. Emacs on
| itself is amazing piece of software, but I had to fight my way
| to setup vim binding on everything.
|
| With neovim you just get that by default. Everything is thought
| around that.
| ngai_aku wrote:
| In what scenarios were you reaching for your mouse within
| emacs?
| wilsonnb3 wrote:
| perhaps onivim would be a good VSCode alternative for you, I
| think they have a mode like the browser vim extensions that
| labels everything on screen with a key you can press instead of
| clicking.
|
| https://onivim.io/
| nulld3v wrote:
| Onivim is no longer being developed :(
| satvikpendem wrote:
| Onivim development has stopped, it is now abandonware: https:
| //github.com/onivim/oni2/issues/3811#issuecomment-9103...
| rzzzt wrote:
| SpaceVim is also a fine contender with its LSP support:
| https://spacevim.org/
| mplanchard wrote:
| I used to use this before I switched away from VSCode for greener
| pastures. It was far and away the best option for vim editing.
| It's great because you can still make use of any neovim plugins
| you have without needing extra VSCode extensions.
| drew-y wrote:
| What are your greener pastures?
| dcow wrote:
| helix is pretty nice if you're willing to challenge your
| traditional vim editing model. vim is action -> selection.
| helix is selection -> action. Beyond that helix feels like a
| modern vim. LSP natively supported. DAP as well. Very little
| configuration and bootstrapping to wade through.
| doomrobo wrote:
| Would love to see if people have a good experience with this. The
| only thing keeping me on neovim is the ergonomics of my config.
| If I can have that, PLUS the discoverability of all the LSP
| features, hovering, consolidated error messages, etc. without it
| breaking all the time, I would switch in a heartbeat.
| aussiesnack wrote:
| For unrelated reasons I've gone back to neovim. But I used this
| in vscode for about a year. It works well. I found it got stuck
| once a day or so and I had to restart vscode. That might have
| improved by now. Having your keybinding-related config spread
| out across so many different places (nvim's config, vscode's
| preferences and keybinding files) is a bit annoying, and I
| found after initial setup I kept forgetting what was where. And
| then whatever vi plugin you use, vscode is never going to be
| entirely consistent about keybindings outside of the main
| editing panes.
|
| Those relatively minor annoyances aside, vscode-neovim is
| perfectly workable for daily use.
| Jenk wrote:
| Been using it for a couple of years. No problems.
|
| You don't get the "absolute fullest" (neo)vim experience
| because you don't get the buffers/panes like you do in nvim
| though.
| linsomniac wrote:
| FYI: LunarVim is a neovim config that integrates all the LSP
| and treesitter stuff. I've been using it for around 6 months
| now and am loving it. However, I'll admit that I went into it
| looking for a vim config that would allow me to ditch the vi
| configs I had been carting around for decades, including a lot
| of half working plugins, so I've tried to modify the stock
| LunarVim configs as much as possible. So it'll depend on how
| much of the ergonomics of your config is based on
| customizations, YMMV.
| thegeomaster wrote:
| Have you tried coc.nvim? I was in the same boat as you, trying
| to painlessly move away to a different editor with Vim
| keybindings or such, because I just couldn't get LSP stuff to
| work without constantly breaking. Since I started using Coc, it
| all just works magically, I just need a `:CocInstall` if I'm
| working in a new language.
| aidos wrote:
| I would say that native LSP support in neovim has improved
| and stabilised a lot recently.
| bobbylarrybobby wrote:
| I find that on the whole it's much speedier, albeit a tad
| buggier, than the "official" vim extension. I think in another
| year it will be more or less perfect.
|
| If you're talking about keeping your Neovim config: yes, due to
| the Neovim extension using the actual Neovim program (this was
| one of the new Neovim features: it includes a vim server that
| processes keystrokes and sends updates for use in a different
| UI). So it has no problem reading your vim config at startup.
| CalChris wrote:
| I have used VSCode-Neovim on OSX since roughly NVIM v0.5. It is
| quite simply the best vim environment I've ever used and I've
| used quite a few. I date myself back to vim, back to vi and even
| to TECO. I pair this setup with the clangd LSP extension which
| makes it even more awesome. This is editor heaven.
|
| However it isn't perfect, yet. Command mode is still a work in
| progress and I use command mode a lot. Navigation with the space
| bar screws up enough that I've switched to the arrow keys (which
| are smaller). A few others but I haven't checked to see if
| they're fixed already.
|
| VSCode-Neovim is actively worked on and gets better with each
| release.
| ilovecaching wrote:
| You might be able to convince me that for certain languages and
| tasks, a Jetbrains editor is better than using a plugged up Vim
| or Emacs. And the up front cost is well known, and their
| corporate model is easy to understand.
|
| You'll never convince me, however, that Microsoft's embrace,
| extend, extinguish partially proprietary editor that uses the
| same LSPs as any other LSP client should be used by anyone. I
| wouldn't touch it with a 100 foot pole.
|
| There are turn key solutions for both Emac, Vim, and Neovim. They
| can all talk to LSPs, have DAP clients, fuzzy finders, file tree
| explorers, project managers, remote editing (terminal editors are
| by nature the ultimate remote editors).
|
| Why isn't he world would you put neovim inside of VSCode when you
| could just _use_ neovim directly via GUI or terminal.
___________________________________________________________________
(page generated 2022-11-22 23:00 UTC)