4 ms·

I've been using vim forever. I'm fluent in editing files. But what never clicked for me is working with several buffers, making lookups across files, using ctag

I've been using vim forever. I'm fluent in editing files. But what never clicked for me is working with several buffers, making lookups across files, using ctags/lsp and so on. The right setting for me is Vim within an IDE (nowadays VSCode) but I've found it too complicated to try to turn it into an IDE. I find it appealing to be able to do all your work within tmux/vim, and I know a lot of great coders work that way but it's been too much hassle for me. I also wonder if Vim is a productivity gain at all. I like to be able to navigate/edit a file without taking off my hands from the home row, and also quickly edit a file when I'm in the terminal. But not sure it really makes that much of a difference when you know your VSCode/MacOS shortcuts, and I suppose that with proper configuration, you can also edit file remotely with VSCode and restrict the need for edition within a terminal.

lvncelot 4y ago
> I also wonder if Vim is a productivity gain at all. The big productivity gain for me doesn't come from faster editing due to the shortcuts, per se, but from the golden combo of modal editing and macros. Due to how you treat similar looking text in vim, macros are much more powerful than something like multi-line-cursors, which break down when you want to, for instance, delete the first part of 5 pascalCased variables with different lengths. Luckily, iirc, the vim integration in VSCode supports macros, so people who want to keep working in VSCode because of the excellent ecosystem can still have the best of both worlds.
- mkingston 4y ago
  How would you achieve your example with macros? My inclination would be to do this with regex replace and I can't think how I'd do it with macros. I guess there's some functionality I'm missing? Jump-to-first-upper-case-character?
- andoryuu 4y ago
  > delete the first part of 5 pascalCased variables with different lengths In VSCode there are available bindings for subword navigation (shortcuts starting with cursorWordPart).
worksonmine 4y ago
There are probably people who are very effective in vscode and the likes. But my patience is tested anytime I'm helping someone or pair programming and I have to watch them navigate the code and make their edits. In my head all I can think of is all the ways it could be done faster in vim, so it's absolutely a productivity gain, even if it's just a plugin for vscode.
- Hendrikto 4y ago
  ”Some people are inefficient with X“ does not mean X is inefficient. They may just be bad at using X.
  - worksonmine 4y ago
    While I get what you're trying to say there are benefits to modal editing that learning all the keybindings in X can't replicate. It's difficult to explain and has to be experienced to fully understand. As a quick example what are the vscode equivalents of I and A to enter insert mode in the beginning or end of a line? These small things quickly add up.
    - modernerd 4y ago
      These days if someone using VS Code asks me how they could be faster, I would be much more inclined to give them some tips that work in VS Code than I would be to encourage them to learn Vim or install a Vim extension. Ctrl-a and Ctrl-e do what you say in VS Code (same amount of keypresses as “I” and “A”, or fewer if you're in insert mode in Vim, and you never need think what mode you're in). Ctrl-w gives you visual selection of the word under the cursor. Repeat to extend the selection (similar to nvim-treesitter's init_selection and node_incremental, but you don't have to set up treesitter and bind shortcuts or learn how to use visual mode). I use Neovim and learned to use VS Code without Vim extensions (to help/teach others, and out of professional curiosity!). Editor “X” absolutely can replicate features from Vim well enough in a lot of cases for the differences not to matter too much, because editor X also does some things better or faster than Vim. Plus we can fill in many gaps that really bother us with extensions. For example, this extension for VS Code lets you switch the cursor from the start to the end of a selection similar to 'o' in visual mode in Vim: https://marketplace.visualstudio.com/items?itemName=rioj7.select-by https://marketplace.visualstudio.com/items?itemName=rioj7.se.... What _does_ seem to be true is that people who use editor “X” are sometimes less vulnerable to spending their free time learning the features and shortcuts of their editor that would make them just a little bit faster. Vim/Emacs users tend to do that because for us text manipulation and editor hacking are a weird kind of hobby. But I pair with a lot of senior devs who are _very_ fast with VS Code/IntelliJ these days without Vim extensions. I have also spent much less time making VS Code completely keyboard-driven than I have customising my Neovim config to achieve largely the same abilities (only with Neovim I also lack a lot of healthy things like screenreader support). In VS Code I just needed: - File Browser (keyboard-driven file nav/creation without using the tree view): https://marketplace.visualstudio.com/items?itemName=bodil.file-browser https://marketplace.visualstudio.com/items?itemName=bodil.fi... - Edamagit (keyboard-driven git commits): https://marketplace.visualstudio.com/items?itemName=kahole.magit https://marketplace.visualstudio.com/items?itemName=kahole.m... - [Optionally]: VSCodeVim ( https://marketplace.visualstudio.com/items?itemName=vscodevim.vim https://marketplace.visualstudio.com/items?itemName=vscodevi... ) or VSCode Neovim ( https://marketplace.visualstudio.com/items?itemName=asvetliakov.vscode-neovim https://marketplace.visualstudio.com/items?itemName=asvetlia... ).
gfaregan 4y ago
I'm not sure if it's much of a productivity gain, but the way I have it set up it is really easy to navigate quickly and precisely through buffers, folds, characters, etc. And it always works once I've installed my config files without any further messing around.
LinXitoW 4y ago
To possibly answer your question, think about conveniences that every editor gives you: Editing per (UFT8) character, instead of code points, or bytes or even bits. Would that make you less efficient? I'm sure it would. Conversely, saying "delete in parens" instead of "move forward 5, delete back 10" is also a real gain. That being said, use what you have. With editing, and navigating the same file, Vim or it's emulations are almost always better, but most editors offer great cross-file features you should also use, like the "shift shift" in Intellij IDEs, or "ctrl-p" in vscode.

lvncelot 4y ago

> I also wonder if Vim is a productivity gain at all. The big productivity gain for me doesn't come from faster editing due to the shortcuts, per se, but from the golden combo of modal editing and macros. Due to how you treat similar looking text in vim, macros are much more powerful than something like multi-line-cursors, which break down when you want to, for instance, delete the first part of 5 pascalCased variables with different lengths. Luckily, iirc, the vim integration in VSCode supports macros, so people who want to keep working in VSCode because of the excellent ecosystem can still have the best of both worlds.

mkingston 4y ago
How would you achieve your example with macros? My inclination would be to do this with regex replace and I can't think how I'd do it with macros. I guess there's some functionality I'm missing? Jump-to-first-upper-case-character?
andoryuu 4y ago
> delete the first part of 5 pascalCased variables with different lengths In VSCode there are available bindings for subword navigation (shortcuts starting with cursorWordPart).

worksonmine 4y ago

There are probably people who are very effective in vscode and the likes. But my patience is tested anytime I'm helping someone or pair programming and I have to watch them navigate the code and make their edits. In my head all I can think of is all the ways it could be done faster in vim, so it's absolutely a productivity gain, even if it's just a plugin for vscode.

Hendrikto 4y ago
”Some people are inefficient with X“ does not mean X is inefficient. They may just be bad at using X.
- worksonmine 4y ago
  While I get what you're trying to say there are benefits to modal editing that learning all the keybindings in X can't replicate. It's difficult to explain and has to be experienced to fully understand. As a quick example what are the vscode equivalents of I and A to enter insert mode in the beginning or end of a line? These small things quickly add up.
  - modernerd 4y ago
    These days if someone using VS Code asks me how they could be faster, I would be much more inclined to give them some tips that work in VS Code than I would be to encourage them to learn Vim or install a Vim extension. Ctrl-a and Ctrl-e do what you say in VS Code (same amount of keypresses as “I” and “A”, or fewer if you're in insert mode in Vim, and you never need think what mode you're in). Ctrl-w gives you visual selection of the word under the cursor. Repeat to extend the selection (similar to nvim-treesitter's init_selection and node_incremental, but you don't have to set up treesitter and bind shortcuts or learn how to use visual mode). I use Neovim and learned to use VS Code without Vim extensions (to help/teach others, and out of professional curiosity!). Editor “X” absolutely can replicate features from Vim well enough in a lot of cases for the differences not to matter too much, because editor X also does some things better or faster than Vim. Plus we can fill in many gaps that really bother us with extensions. For example, this extension for VS Code lets you switch the cursor from the start to the end of a selection similar to 'o' in visual mode in Vim: https://marketplace.visualstudio.com/items?itemName=rioj7.select-by https://marketplace.visualstudio.com/items?itemName=rioj7.se.... What _does_ seem to be true is that people who use editor “X” are sometimes less vulnerable to spending their free time learning the features and shortcuts of their editor that would make them just a little bit faster. Vim/Emacs users tend to do that because for us text manipulation and editor hacking are a weird kind of hobby. But I pair with a lot of senior devs who are _very_ fast with VS Code/IntelliJ these days without Vim extensions. I have also spent much less time making VS Code completely keyboard-driven than I have customising my Neovim config to achieve largely the same abilities (only with Neovim I also lack a lot of healthy things like screenreader support). In VS Code I just needed: - File Browser (keyboard-driven file nav/creation without using the tree view): https://marketplace.visualstudio.com/items?itemName=bodil.file-browser https://marketplace.visualstudio.com/items?itemName=bodil.fi... - Edamagit (keyboard-driven git commits): https://marketplace.visualstudio.com/items?itemName=kahole.magit https://marketplace.visualstudio.com/items?itemName=kahole.m... - [Optionally]: VSCodeVim ( https://marketplace.visualstudio.com/items?itemName=vscodevim.vim https://marketplace.visualstudio.com/items?itemName=vscodevi... ) or VSCode Neovim ( https://marketplace.visualstudio.com/items?itemName=asvetliakov.vscode-neovim https://marketplace.visualstudio.com/items?itemName=asvetlia... ).

gfaregan 4y ago

I'm not sure if it's much of a productivity gain, but the way I have it set up it is really easy to navigate quickly and precisely through buffers, folds, characters, etc. And it always works once I've installed my config files without any further messing around.

LinXitoW 4y ago

To possibly answer your question, think about conveniences that every editor gives you: Editing per (UFT8) character, instead of code points, or bytes or even bits. Would that make you less efficient? I'm sure it would. Conversely, saying "delete in parens" instead of "move forward 5, delete back 10" is also a real gain. That being said, use what you have. With editing, and navigating the same file, Vim or it's emulations are almost always better, but most editors offer great cross-file features you should also use, like the "shift shift" in Intellij IDEs, or "ctrl-p" in vscode.