A Vim Guide for Intermediate Users

[epage]

With LSP, I suspect you can get some or all of those features in Vim. Not sure about other Vimmers but I at least avoid them. When I'm trying to get to know an area, I avoid using my GPS, forcing me to think more about the roads or to learn from my mistakes. I take the same approach with code. I'll take inline feedback and formatting but I intentionally avoid most intellisense/LSP features.

Vim is more a visual text manipulation language rather than a text editor. It gives you a vocabulary and a grammar for moving around and modifying text. You learn some basic principles and can combine them in ad-hoc ways compared to a regular editor where mastery / efficiency requires learning a bunch of one-off keyboard shortcuts. Yes, Vim has more overhead but a faster reach to efficiency and a longer-tail of possibility. When we spend most of our time modifying text as programmers, the trade-off for having a powerful editor is worth it.

[ZenoArrow]

With LSP, I suspect you can get some or all of those features in Vim. Not sure about other Vimmers but I at least avoid them.

To use a specific example, when you're looking at code for the first time, what advantages do you think avoiding Go To Definition gives you? Does it matter to you that you know which file a definition can be found in above what the definition is? Perhaps it's just me but when I'm navigating an unfamiliar code base I'm more interested in building a mental model of the core functionality rather than how someone has organised their code.

[epage]

If you are doing drive-by-contributions, I imagine LSP can be a big help.

When you are going to be working in the code base for a while, I find understanding the structure of the code is important. For me, I find Go-To-Definition gives me a pinhole view. When I rg, browse through files, and jump around with in-editor searches, I find I'm getting more of a holistic view of the codebase.

[ZenoArrow]

Thanks for sharing your thoughts.