I don't believe it's possible to have a good vimrc without really grasping some elementary concepts like movements, operators, registers, windows etc. I have recently watched all the Drew Neil's VimCasts[1] and after just a couple of hours I've realized I was missing a lot for at least 10 years. There is also quite a good presentation on YouTube by Max Cantor "How to Do 90% of What Plugins Do (With Just Vim)"[2]. Instead of treating a single vimrc as the best one it's useful to skim through dotfiles and plugins of some influential vim users like Drew Neil[3] and Tim Pope[4]. BTW VimCasts are accompanied by a book. The second edition[5] includes changes introduced by Vim 8.0.
+1 for the Max Cantor presentation - I mostly use stock vim now because of that video... also you can get a lot of mileage from combining :read with shell commands. I like this approach as it forces me to level up my bash.
I sort of disagree with this and think one should extend in the opposite direction- to keep sharp, have an RNN generate some plausible config options / shell commands, and append them to the bottom of your vimrc / bashrc on startup. This results in sort of like a 'chaos monkey' of coding, to prepare you for when real emergencies pop up.
Don't tell me your default method for deleting files is to carelessly throw 'rm -rf' at the issue...if it's "important" and you're using -rf, a part of me thinks "you deserve whatever happens"
I was joking in both comments (clearly running arbitrary shell commands on a personal computer is a terrible idea), but it's not like a careless rm -rf has never happened before
I wonder why text editor preferences are so personal. I use the same editor and probably 90% of the same config as this guy and was nodding along until I saw he remapped B and E. Horrifying! Those are fundamental motions.
I’m always surprised at the number of people who recommend mapping `,` as their Leader key; it’s almost as useful as its counterpart, `;`. I suspect that such people never learned vanilla Vi and use `f`, `t` and related line movement commands.
When I learned Vim, I started with the `vimtutor` tutorial. At the end of the tutorial, it suggests Learning the Vi Editor - by Linda Lamb (O’Reilly)[1] for further reading. I found this book to be excellent for providing a solid grounding on Vi – and its descendants such as Vim. For a while, I constrained myself to using Vim in Vi-compatibilty mode before using the many wonderful features provided by Vim.
I try to keep my vimrc as lean as possible so that I’m not reliant on having it available (even though I have it in a Git repository on my VPS) and it’s only in the last couple of years that I’ve started adding plugins to it (Syntastic and Unicycle).
"I’m always surprised at the number of people who recommend mapping `,` as their Leader key; it’s almost as useful as its counterpart, `;`. I suspect that such people never learned vanilla Vi and use `f`, `t` and related line movement commands."
I've been using vim for years, but I completely disagree with your statement. I rarely find the "," key useful, so to me it was a no-brainer to switch to using it as the leader. I just have ",;" mapped to the functionality that "," used to do.
I use ";" all the time, but searching backwards just barely comes up. Usually, I'll hit "home" and then repeat my "f" search if I need it.
Thanks for different perspective (and to otterpro and tasuki). I use `;` much more often than `,` but I still find the `,` useful when I’ve gone past the position I want to go to, e.g., typing `5fx` when I should really have have used `4fx`.
I agree that we shouldn't use "," or ";". I prefer to use SPACE as the leader key, as it is probably the most prominent key and also easiest to reach, but I can understand why some would use "," or ";" because of it's easy reachability and the fact that those keys aren't as used as often (at least for novice users). Perhaps it should be part of "best practice" in Vim.
> I’m always surprised at the number of people who recommend mapping `,` as their Leader key; it’s almost as useful as its counterpart, `;`. I suspect that such people never learned vanilla Vi and use `f`, `t` and related line movement commands.
I use `,` as Leader, as well as to search back if I happen to `;` over something I was looking for. I don't mind waiting 400ms (my `timeoutlen`).
I was listening to a recent TalkPython podcast with Dougal Matthews titled "Effective Code Reviews". Host Kennedy asks every interviewee what is their favorite editor. Dougal's answer: (44:35-44:48) "I use Vim all the time. Yeah, I work in so many remote servers and VMs that I have some scripts to kind of set up my Vim environment on that machine, and then it's just great."
Who knew it would be that easy to switch to your own personal VIM setup?
The literal worst of vimrc is the _default_ settings of many Linux distributions these days. Colors are fine, but _behavior_-changing stuff is not. I would be happier if package installers included a brief configurator as part of installation.
Do you want to use tabs when you press tab, or spaces? If spaces, then _how many_?
Do you want to automatically (infuriatingly IMO) continue comments and completely wreck the ability to paste text without also _telling_ vim that you intend to paste via the `set paste` command?
Ahhh good old 'set paste'. The setting that has turned away so many. When I watch a novice coworker struggle with vim, the breaking point usually comes when they try to paste directly into insert node. That may be the most valuable of all commands in this discussion.
I've been using VIM for a while, and I'm always delighted to read articles or examples of good .vimrc's, but this one tops them all, because of the perfect balance of cool features and concise explanations. Good job, OP, what a wonderful blog post, I learned a couple nice things too!
Now just add the section about uploading it to your GitHub so all new servers get setup with a simple git clone, and any new changes can be propogated around with push/pull.
For anyone interested in this topic, [0] contains the best setup I've found for storing dotfiles in a git repo, then linking them with GNU Stow. Steps are just:
git clone https://github.com/me/my-dotfile-repo
cd my-dotfile-repo
stow --target=$HOME zsh
stow --target=$HOME vim
...
Sorry if this is a super naive/dumb question, but why wouldn't I simply write a "build" script that copies files out of my dotfile repo to where they're supposed to go?
1) It's cumbersome, and you'll need to specially handle things like deleting files. I personally wouldn't be comfortable having a homebaked script rm stuff in my home directory.
2) By using copies instead of symlinks you'll need to run your script Everytime you make changes and be careful to edit only your clone instead of the target location.
I second this and highly recommend using stow for this. It takes all of 30 seconds to learn, took me maybe 10 minutes to round up my various dotfiles and move them into a central folder, and, combined with putting them in a VCS, has made life sooooo much easier.
I switched over to Stow last time I set up a new machine and now regret not having discovered it long ago. It always amazes me how for basically any problem you might have there's probably a GNU project to resolve it.
If I understand it correctly you generate the program from that file by removing all the non-code text, right?
This is very well documented , but not "actually" literal programming. It's a losing battle over this definition but since you said actually I'll go for it one last time :p
In literal programming, the order of the explanation dictates the flow of text. Conversely, well documented source code follows the order of the program.
The literate programming paradigm, as conceived by Knuth, represents a move away from writing programs in the manner and order imposed by the computer, and instead enables programmers to develop programs in the order demanded by the logic and flow of their thoughts.[2] Literate programs are written as an uninterrupted exposition of logic in an ordinary human language, much like the text of an essay, in which macros are included to hide abstractions and traditional source code.
Literate programming in this specific case would include a big overview of the entire file somewhere with references to each section. These would then be pulled in and included at compile time.
> In literal (sic) programming, the order of the explanation dictates the flow of text. Conversely, well documented source code follows the order of the program.
org-mode supports noweb-like chunks, so you can do "real, Knuth-like" literate programming. It just makes little sense in the case of configuration files because they're just a collection of mostly-independent bits.
It's code, but most of it is simply (use-package ivy ...) or (setq tab-width 3.14), where's the value in chunks? The typical Emacs configuration doesn't contain data structure definitions, algorithm implementations, or error handling that can be more appropriately reorganized for a reader.
I've been using it for a month or so. It's very easy to set up and configure, and it's built with evil-mode in mind. It also has very good modes for development - I use it for Go and everything including completion and hinting function signatures worked right out of the box once the Go layer was installed (which is one line in your .spacemacs)
My problem with Emacs, I'm a bit of a visual person and Emacs doesn't have tabs. There's all sorts of half baked tab system that don't do what the real thing in Vim does.
And everytime someone I ask about this someone point me to some "superior paradigm". It ain't superior if I don't like it :)
Did the emacs fundamentals tutorial. Installed evil. Got a little frustrated when some things didn't work exactly as expected. Also there is a weird TLS bug with the melpa and marmalade repos and the packaged emacs that debian stable offers. If I need to compile something then Neovim starts looking more attractive (I'm not aware of any package for debian stable atm but am happy to be corrected).
Now I'm just looking to try to solve my problems in vim again :)
[1]: http://vimcasts.org/episodes/ [2]: https://www.youtube.com/watch?v=XA2WjJbmmoM [3]: https://github.com/nelstrom/dotfiles [4]: https://github.com/tpope [5]: https://pragprog.com/book/dnvim2/practical-vim-second-editio...