Good read. My strategy for avoiding all the vim porn and "plugin-madness" is to never install a plugin or mapping/override without learning to do the thing manually in vanilla vim.
This way you'll KNOW if that plugin is really worth the bloat, and if you do end up away from your config on a remote server you're just mildly uncomfortable instead of dead in the water.
I personally find vin to be a good tool for editing text without leaving the terminal. But when I’m writing a lot of code, I’ve found the vim ide concept to be far more trouble than its worth.<p>Modern IDEs like VSCode + Vim bindings is my preferred platform
Counterpoint: it's my editor on my computer, the most important thing is me understanding my own tools and being able to use them comfortably. So while I try to not deviate too much from standard shortcuts, I'm not afraid to make mappings for things I rely on more. At the same time I also dislike complex plugins that add crazy amounts of extra complexity.
Bro I don't mean to make you the shining example of what I'm talking about but can we please try to be succinct with write-ups? The whole first half of the article could've been summarized with a single sentence: "As is typical with newbie vim enthusiasm, I spent many hours producing a 1000+ line vimrc over a long time that I eventually realized complicates my word editing process more than it helps."<p>I mean come on..
I can't help remapping ; to : and vice-versa. Can't think of the last time I needed the default ; and sparing my pinky from having to hit shift every time I want to ;q is a game changer. Obviously, that's annoying to change in every vim install but I just have a very light .vimrc that I curl in every new box
The only map that I would say is an absolute improvement over the default is<p><pre><code> map ; :
</code></pre>
Using : is a waste of a keystroke (ie. shift) in an editor that I chose specifically to reduce chorded key combos.
> I started to look at Vim as a line editor first and a text editor second. Indeed, if you look into it, the original intention of Vi was to serve as a visual front for a line editor called ex. And I think it shows. What it means in practice is that Vim encourages you to start your edits with the cursor placed at the start of the line. When you are in this place everything goes smoothly. And when you go against the grain all kinds of bad things start happening.
I agree that defaults are good! I have to at least "set number" in my vimrc, and most importantly get rid of those horrible swap files.<p>Here's my minimal vimrc if anyone is curious <a href="https://gitlab.com/jane314/settings-and-scripts/-/blob/master/vimrc" rel="nofollow">https://gitlab.com/jane314/settings-and-scripts/-/blob/maste...</a>
I think everyone knows the rabbit hole problem that this kind of article is warning against. Especially for beginners.<p>But as a counter-example:<p>I've done most of those "types of vim porn" I guess, then moved to spacemacs, then my own custom emacs/evil setup. Always with some similar window manager and command line tweaking as well.<p>Probably spent a hundred hours on all this kind of thing easily, in a small number of big bursts.<p>Over 20 years.<p>During which time I've had a very comfortable, understandable, debuggable and pleasant dev environment that made development, testing, documenting, debugging and planning a thing I can just work on without really thinking about the tools. Switching between the files, the command line, the failed tests, the docs, the repls and the browser tabs as fast as my eyes move.<p>I don't need to break out that one efficiency-tradeoff XKCD either because while it was definitely mathematically worth it time-wise, there is no question the wins were happiness-wise and not-swearing-at-my-tools-wise (just the project code).<p>Learning to type was probably a better ROI, can't think of what else is in the ballpark though.
If your .vimrc is minimal, you will have a pretty good time using systems that implement "vim like" text editing. Take Overleaf for example, no vimrc is available, but I'm quite happy with what I got, and sometimes I even forget I'm in the browser.
<p><pre><code> The simple truth was that, no matter how
much energy I invested in my custom configuration, the
people who built and designed Vim knew it a lot
better than me.
</code></pre>
That would make sense if the defaults we were talking about had been carefully selected five or ten years ago or shown any signs of evolution since they were first laid down in 1975. If I was editing code in the languages they used in environments like theirs using underlying tools that performed like their tools in a codebase the size of `ex`'s, I'd certainly trust the defaults. But I'm not doing any of those things.<p>Today, I work in a codebase whose <i>human-readable source alone</i> might be larger than any installed digital storage system that existed when vi's shortcuts were chosen. By necessity I navigate it with semantically-aware indexing and information-retrieval tools that would have been miraculous back then. My edits are guided by static analysis and effected with automated refactoring and code generation tools.<p>My configuration doesn't suit my environment as well as vi's defaults suited their environment. It does, however, suit my environment better than vi's defaults do.<p>And let's not even get into emacs configurations. :P
I have followed a similar vim path, although my vimrc file never was close to 1,000 lines long! I used to use many plugins though including nerdtree, airline, and surround. But in the end it was always difficult to maintain that setup long term.<p>I do try to add a few shortcuts to my .vimrc file though which is pretty minor:<p>- jk maps to escape<p>- oo and OO map to create a new line below/above but stay in normal mode<p>- leader \ to clear highlights<p>and that is about it!
I once decided to try an online vim profile generator when setting up after a disk crash, to save time re-creating my simplistic .vimrc. It was awful. All sorts of things I never used normally in Vim, forced down my throat. Manpage-reading plugins, bizarre brace handling, different buffer control, and a Day-Glo colorscheme implemented in some annoying-to-override fashion.
Here is my only remapping: map Q <nop><p>Whenever I use vim without my config I wind up hitting Q and entering ex mode and wishing I had my config.<p>I've used vim on and off for at least 6 years and have never installed a plugin. Vim is great for quick edits, arranging text in temporary files (control x + control e in the terminal, quit without saving), moving chunks of code around, running macros. Its also great to use the keybindings in your favorite electron IDE.<p>I'm just not a "plugins" person. I've been trying to set up a python environment in emacs for a while and it hasn't been fun. Its an iterative process of installing a few plugins, getting something buggy and slow to use, and eventually getting fed up and restarting from a minimal config file.<p>Emacs has been amazing for magit alone, I just wish I was good enough at it to use it for more things.<p>Vim? Its my barebones text mover that has keybindings in countless apps. That's all it needs to be.
I can't imagine remapping any of the standard commands. What if you have to edit something as a guest on someone else's system? Just get used to it and deal. I've been using it (in "vi" form) daily since 1985 or so and doing any of those remappings would drive me nuts.
> Now, after all the struggle, my vimrc is around 50 lines in length. It only includes simple and frequently used commands, like this map to toggle search highlighting with ctrl-/<p>Isn't the usual one (perhaps it's even default) leader (default \)-l?<p>I used to use Esc, which honestly I really do prefer (intuitivly - I'm in 'search mode', ESC to get back to normal), but it's somewhere between painful and impossible to portably implement without weird bugs, so I eventually gave in.
Regarding to the remapping for Y, I also only memorized y$, c$, and d$ and they seem more natural to use for me.<p>Therefore, I remap D to delete the whole line, but do not put it into any register. This allows me to cut a line with dd, while I can throw away a few other lines with D to clean up around the target location, before finally pasting with p.<p>nmap D "_dd
vmap D "_dd
It's been a while since I started using vim. I can see some similarities. Though, I didn't really do much configuration in the early days. Currently, I have pretty much no configs when it comes to key maps or some custom or shortcuts. I only add plugins for code completion and highlighting. Nothing else.
My journey started when someone just dropped their .vimrc and I tried it out... So I'll do the same: <a href="https://tinyurl.com/y4d7rx6f" rel="nofollow">https://tinyurl.com/y4d7rx6f</a><p>Typically I clone that into my home directory. Then I link everything to it with:<p>ln -s ~/vim/.vimrc ~/.vimrc && ln -s ~/vim ~/.vim<p>The .vimrc is kind of documented, but a quick version is:<p>tt: select a file name to open into a new buffer<p>fr and fR: go forward or backward through buffers (open files)<p>fd: close buffer<p>f2: if the needed commands are installed, reformat code<p>There's a few other remappings, but those are the most frequent ones I use, hence making it easier.<p><tab> completion works everywhere as well. There's a bunch of other stuff for navigating windows and tabs, but once I realized that "buffers" are actually the "vim way" of file navigation, I stopped using those short cuts.<p>Edit: Yes I realize this is probably what the article is complaining about, but oh well.
The three things I have in my .vimrc are<p>se ts=4 #1 tab= 4 spaces<p>se ic # ignore case when searching<p>se nows # don't wrap to top when you reach end / beginning of file in a search.<p>I could add a lot more, eg a json / xml formatter but never got around to it in 21 years.
> This article describes my Vim journey, starting from heavy personal customization and ending with a renewed love for defaults<p>this exact pattern is found in so many vi|m articles and is touted as a triumph of vim's default patterns, when it is really a failure of vim to support whole ranges of functionality. as a daily user of neovim, i know that vscode is a superior alternative and am waiting for a month off to transfer all my vim customizations to a real ide
Ever since I started using vim exclusively for development a couple of years ago, I deliberately decided not to use plugins nor to edit the defaults unless strictly necessary. Nowadays, my .vimrc is just a few lines, all regarding indentation.<p>It had worked for me so far and I never really felt any less productive than when I used IDEs or VS Code.