4 ms·

Not to be too pedantic but shouldn't that be ddGp? Also, have you tried the Vim plugin for VSCode?

by barbs 6y ago

IggleSniggle 6y ago
I've tried the Vim plugin for VSCode a few times personally, but I don't trust it. It's incomplete, and it has its own secondary understanding of history that can get you into trouble when it interacts poorly with VSCode's own history. Anyway, that was my experience for my short time using it. I'm curious if there are any longtime vim users using VSCode with the Vim plugin, and if so, what are their experiences, and why do they use VSCode with a Vim plugin instead of just using vim itself?
- BadInformatics 6y ago
  I used to, but switched to https://github.com/asvetliakov/vscode-neovim https://github.com/asvetliakov/vscode-neovim. It's much faster, doesn't lag the editor at all and has less of an impedance mismatch because it uses Neovim under the hood instead of trying to emulate functionality from scratch. There are a few reasons why I use a vim plugin instead of vim proper for most day-day work: 1. I do plenty of data science-y stuff that requires support for good visuals. Vim's support here is pretty lackluster and Jupyter's Vim mode sucks. VS Code has a great interactive mode with full autocomplete and a dedicated window that records plots/output history. 2. Language servers and LSP plugins are so much easier to manage. I rarely if ever have to babysit updates and I don't have to install a bunch of system-wide dependencies to get certain ones to build. 3. Making the above (and all other fancy VS Code functionality) work on multiple remote machines is a breeze. The normal Vim workflow would require cloning dotfiles (not a big deal), running setup with something like GNU Stow (almost never installed) and then futzing around with LSP plugins as in 2). 4. Built-in rendering of rich docstrings/doc pages (think Markdown, Sphinx RST). I want to say certain extensions/languages support LaTeX as well, which would be a bear to read in Vim.
  - IggleSniggle 6y ago
    I know a lot of folks don't read comments over a week old, but just in case you do, just want to say: THANK YOU. I took the plunge tonight into neovim/vscode-neovim and it is the solution I've been wanting without knowing it was what I wanted.

Not to be too pedantic but shouldn't that be ddGp? Also, have you tried the Vim plugin for VSCode?

by barbs 6y ago

Not to be too pedantic but shouldn't that be ddGp? Also, have you tried the Vim plugin for VSCode?

I've tried the Vim plugin for VSCode a few times personally, but I don't trust it. It's incomplete, and it has its own secondary understanding of history that can get you into trouble when it interacts poorly with VSCode's own history. Anyway, that was my experience for my short time using it. I'm curious if there are any longtime vim users using VSCode with the Vim plugin, and if so, what are their experiences, and why do they use VSCode with a Vim plugin instead of just using vim itself?

BadInformatics 6y ago
I used to, but switched to https://github.com/asvetliakov/vscode-neovim https://github.com/asvetliakov/vscode-neovim. It's much faster, doesn't lag the editor at all and has less of an impedance mismatch because it uses Neovim under the hood instead of trying to emulate functionality from scratch. There are a few reasons why I use a vim plugin instead of vim proper for most day-day work: 1. I do plenty of data science-y stuff that requires support for good visuals. Vim's support here is pretty lackluster and Jupyter's Vim mode sucks. VS Code has a great interactive mode with full autocomplete and a dedicated window that records plots/output history. 2. Language servers and LSP plugins are so much easier to manage. I rarely if ever have to babysit updates and I don't have to install a bunch of system-wide dependencies to get certain ones to build. 3. Making the above (and all other fancy VS Code functionality) work on multiple remote machines is a breeze. The normal Vim workflow would require cloning dotfiles (not a big deal), running setup with something like GNU Stow (almost never installed) and then futzing around with LSP plugins as in 2). 4. Built-in rendering of rich docstrings/doc pages (think Markdown, Sphinx RST). I want to say certain extensions/languages support LaTeX as well, which would be a bear to read in Vim.
- IggleSniggle 6y ago
  I know a lot of folks don't read comments over a week old, but just in case you do, just want to say: THANK YOU. I took the plunge tonight into neovim/vscode-neovim and it is the solution I've been wanting without knowing it was what I wanted.