After years of a love/hate relationship with Vim (I love what it does, but have configuring it), I had an epiphany: by sticking with the defaults, whether they are my preferred choices or not, I can instantly understand how to use Vim in any environment. Once you get used to biting the bullet and hitting escape instead of jj, or ctrl+c, it just works, everywhere.<p>If you abandon the urge to pimp out your Vim with a billion plugins, and just use it raw, it's a kind of editor Nirvana. Let go of your desires and live without want :)<p>Of course, that's just me. I understand why someone would want to turn Vim into their personalized powerhouse editor with IDE powers, with their .vimrc a 'git pull' away.<p>But I've learned to live with the humble defaults, and it's made life easy.
Been using vim since 1998 and rarely stray unless I'm typing notes for something unimportant and them I use Nano.<p>Back in the day when I was a Unix admin, we often worked in full screen terminals and when editing a config file didn't like having to close the vim instance to go look at something, so learned about this little gem:<p>:sh (go back to shell and do your thing and leave vim running)<p>Ctrl-d to return to intact and running vim instance.<p>As an aside, if you decide to use nano to edit config files, make sure you use nano -w (no wrap), otherwise you may find yourself with a non-bootable OS instance.
This video of a talk that Bram Moolenaar (the author of vim) gave at Google in 2007 has some pretty good advice.<p><a href="https://www.youtube.com/watch?v=eX9m3g5J-XA" rel="nofollow">https://www.youtube.com/watch?v=eX9m3g5J-XA</a><p>Mainly the idea is to not try and learn everything about vim, but instead pay attention to how you use it, and find things that are inefficient or could be easier, and <i>then</i> go figure out how to make vim do that thing more efficiently.
To anyone who hasn't tried it - <a href="http://www.vimgolf.com/" rel="nofollow">http://www.vimgolf.com/</a> is probably the quickest and most fun way to take your skills to the next level.
I started my programming career determined to be a vim guru and do all my programming with vim.<p>This was misguided and after a year of wasted productivity and wasted time fiddling with plugs and dealing with broken stuff (surely by my own hand) I switched to a professional IDE and I rapidly became a much better developer.<p>I use vim constantly now but in it's most plain vanilla form, for the purpose of editing files when logged into Linux systems. That's all I use it for.<p>I really wish however that every Linux system had a clone of the old DOS edit command which was beautifully simply and straightforward and met most needs highly intuitively.<p>As a sidenote: can I just say that PyCharm is an incredible IDE and I can recommend it heartily to anyone. If your job is programming then it is many times over worth paying the money for the professional edition.
Everyone is missing the most important contribution of vi[m].<p>Vim defines an ergonomic set of rules for text navigation and manipulation, often implemented by very simple key bindings. This is wonderful.<p>The Vim editor implements all these rules, but the Vim's plugin ecosystem is a disaster. Hacks pile upon hacks. Noone understand Vim scripts. Vim scripts are easily broken and do not interoperate well with other scripts.<p>These set of rules can be easily implemented by other editors, as evidenced by many IDEs supporting Vim key bindings. Although these editors may not support all the above rules, they are pretty close (see the evil plugin in Emacs) and can replace Vim in daily usage.<p>The editor war is over. Vim's keybinding is superior. But the longevity of a text editor lies in its extensibility. For this, Emacs wins in the long run.
I rarely ever use actual vim, mostly when I'm in the terminal. But I have vim plugins for most IDEs I use (VS code, intellij, XCode). It makes editing so much faster. When I have to get by without it I feel as if someone put weights around my wrists. The reason I don't use Vim is because it's frankly not a smooth experience for most languages (unless you fiddle around a lot, and even then I found Ide+vim plug-in superior). I do hope Neovim will solve this, though I didn't test it because the last time I checked windows support was experimental.
I don't limit my plugin usage on purpose. I will add a plugin if it adds a value I can make use of.<p>Disregarding color schemes here is my list:<p>* FZF<p>* COC (it provides a lot of QoL, functionality of modern editors with it's plugins using an easy seamless yarn add)<p>* Sandwich<p>Very few customizations. Mostly vanilla.<p>Regarding colors, I love to try new ones all the time and my current is scery followed by Gruvbox, and Dracula because they work in Terminal.app and iTerm. They also look nice / easy-on-the-eyes. My friend at work has a thing for Nord and another loves Monokai Pro, but apparently the author wants money for it...? Which seems... different.
I very recently set out to start bringing my vimrc with me when logging into remote hosts and came up with this.<p><pre><code> Host * !github.com
RemoteCommand echo -e "syntax enable\nset ts=2\nset sw=2\n" > ~/.tmp_vimrc && bash -c 'set -a; vi() { vim -u ~/.tmp_vimrc "$@"; }; set +a;bash -l'
RequestTTY yes
</code></pre>
It gets ugly when you get a lot of options in there.<p>It's possible to just curl or scp something in place via RemoteCommand above, or `source: <a href="https://foo.io/vimrc`" rel="nofollow">https://foo.io/vimrc`</a> but my security paranoia lead me to this instead.
Excellent article by the creator of the equally-excellent postgREST. Especially the neato historical material - I didn't know that Vi was directly derived from the ex [and by extension, ed] editor.
I've been using Vim for a couple of years now and I almost can't stand any text editor without VIM-like extension.<p>However, recently I took a liking to Visual Studio Code (with VIM bindings of course). Yes I know, it's terribly bloated and consumes RAM like nobody's business, but the Browser DOM arguably is the successor of terminal emulation in terms of ubiquitous interfaces, and VSC does use the additional power quite smartly. There are graphical hints and tweaks which are next to impossible to achieve in a terminal emulation.<p>I'll still use VIM all the time, especially remotely. But VSC does provide similar extensibility. I somehow wish there was something like VSC, based on web/electron, but more like a Texteditor, less like an IDE. And preferably not controlled by a huge corporation.
I used vim for years, but then Sublime appeared.. although I miss the snappiness of vim, and wouldn't mind to come back. Specifically, I'd miss these nice features of Sublime:<p>1. Multiple cursors!! (and <i>how easy</i> is to use them)<p>2. Real-time preview of regex search<p>3. Package Manager (easy installation <i>and</i> discoverability of plugins)<p>4. Jump to file, jump to function, jump to css selector.. (ctrl+p, ctrl+r, using fuzzy search)<p>5. Project tree in small font (many files at sight)<p>Edit: Here there is a bunch of good stuff: <a href="https://medium.com/@huntie/10-essential-vim-plugins-for-2018-39957190b7a9" rel="nofollow">https://medium.com/@huntie/10-essential-vim-plugins-for-2018...</a>
I remember the first time I ran `vimtutor` in my terminal. A lot changed since then! Although I just stick with defaults since I have my IDE for my day-to-day job.
> <i>Some of the clones:</i><p>><p>> <i>nvi - 1980 for 4BSD</i><p>> <i>[ ... ]</i><p>> <i>elvis - 1990 for Minix and 386BSD</i><p>This is incorrect; nvi is in fact a mid 1990's fork of Elvis, worked over for better POSIX compliance by Keith Bostic.<p>> <i>vim - 1991 for Amiga</i><p>Though that was the first public release, Moolenaar had worked on it since 1988. It was based on Tim Thompson's Stevie, which had been released, in 1987 (noted in the table).
I realized why Vim has always felt a little off to me. The primary navigational commands are mostly on the right hand, which as a left handed person feels very weird to me. While Emacs commands favor neither hand (if anything they favor the left with C-f, C-b, C-a, C-e, C-x C-s, M-x, etc). Just a small observation.
> Oct 2010 - Feb 2014 : Vundle (Discontinued after NeoBundle ripped off code)<p>Looks like Vundle has an MIT license. rip off usually implies something negative or dishonest. Copying MIT licensed code is a normal and encouraged activity.
I don't think I'll ever be able to internalise all the features of Vim.<p>I've been using it for > 10 years now but I still find myself learning (and sadly forgetting) new features when reading articles like these.
Shameless plug: A few days ago a write a quick reference for Vim too, checkout <a href="https://github.com/p1v0t/Doctor" rel="nofollow">https://github.com/p1v0t/Doctor</a>
In addition to the [Neo]Vim, I can also recommend vifm[1] - vi-like file manager. It supports vi-like key bindings, similar configuration, and color schemes[2]. Moreover, it can be integrated[3] with Vim itself.<p>[1] <a href="https://github.com/vifm/vifm" rel="nofollow">https://github.com/vifm/vifm</a><p>[2] <a href="https://vifm.info/colorschemes.shtml" rel="nofollow">https://vifm.info/colorschemes.shtml</a><p>[3] <a href="https://github.com/vifm/vifm.vim" rel="nofollow">https://github.com/vifm/vifm.vim</a>
Just finished reading this book, “Ed Mastery”. I can’t tell if it’s “worth the money” - not sure if learning ed(1) is worth anything- but it’s fun to see the design decisions made way back in the 70s still being present in vim<p><a href="https://www.amazon.com/Ed-Mastery-Standard-Unix-Editor-ebook/dp/B07BVBSDNZ" rel="nofollow">https://www.amazon.com/Ed-Mastery-Standard-Unix-Editor-ebook...</a>
I'm a React Developer that uses Vim, and whilst I have reduced my .vimrc down a lot since I started playing with vim, I still use about 15 plugins such as Deoplete, tern, ale, fzf, a language pack (I'm always messing around learning new languages), and then a selection of Tim Pope addons.<p>At 120 lines, I consider my .vimrc quite light.. Although I'm not sure what others will think.
I'm deep into vim and have recently seen some things that colleagues are doing with VS Code. I have to admit, I'm tempted.<p>But I'm so used to vim + tmux now, it's hard to imagine working with something different.
There's only one thing I need to improve my VIM experience: a way to set style options (and search paths) for each git workspace. I've yet to find a non-hairy way to do this. Help!