Ten Years of Vim
matthias-endler.de
matthias-endler.de
Sometimes you do some things then undo and redo trying to get back to a certain point in time. In vim you can step forward and back through all this by doing "g-" or "g+" to travel backwards or forwards in time. Or you can say ":earlier 50s" to go back to where you were 50 seconds ago.
Most editors treat undo as a linear thing, you undo and you redo. But once you undo and then do some things, it starts looking more like a tree than a line. It's not frequent, but sometimes I just need to say "I know what I had was what I wanted 5 minutes ago."
So once you're somewhat happy with what you've got, write the file, and then continue editing, repeat, and you can revert back to any previous saved file state.
Funny you mention that though, a coworker opens files in vim and does changes and tests but keeps it open if he's going to try something else so he can always go back to those other changes (guessing he reverts the code, then opens yet another vim window). I work with a lot of VI(M) coders but they barely take full advantage of VI(M). I just use IDE's or Emacs / VS Code (w/ X Forwarding more recently) personally makes it easier to find the fancy features with a UI.
I'll share that time travel feature to my VIM coworkers maybe it'll save their tail sometime.
undofile
undodir
In photoshop you have an undo paintbrush. I'd love to have something similar in my text editor.
map <C-j> :tabn<CR>
map <C-k> :tabp<CR>
cnoreabbrev split tabeI only use a very small number of it's features:
* `:tabe` Create a new tab
* `:e .` Start browsing files in that tab
* `:w` Write the file
* `:q` Quit the file (`:q!`, seriously, please do quit the file)
* CTRIL+SHIFT+UP/DOWN To switch tab (doesn't reliably work on every machine)
* `/WORD` To search for something
* `:NUM` To go to a specific line
* `i` To insert
* SHIFT+V to select lines
* `d` To delete lines
* `x` To extract lines
* `y` To "yank" (copy) lines
* `p` To paste lines
>Here are a few things I wish I could do better:
I don't have a great memory, so memorizing more than what I use every day is a little too much. One thing that I'm working on remembering is the ability to replace strings (although I don't really like regex).
>Would I learn Vim again?
I'm yet to experience anything compelling enough to stray me away. The advanced features are there if I ever need them, but for the most part I am free to have a lightweight editor.
Oh, so you are using an improved version of Vi IMproved? ;)
Also, search uses different word separators from vim: In vim "foo_bar" is a single word that will be skipped by pressing "w". But in evil-mode the "_" is a word separator, so the above is three words. That breaks my flow every time.
Some of this might not be due to vanilla evil but due to the fact that I'm using it through Spacemacs.
This is my two cents. If by any chance anyone would know off the top of their head how to fix these, I'd be greatful.
https://www.emacswiki.org/emacs/UndoTree
Regarding "_", you can set up Emacs to treat _ as word constituent by modifying the syntax table. For example:
(modify-syntax-entry ?_ "w")
https://www.gnu.org/software/emacs/manual/html_node/elisp/Sy...
If you learn "w", which just means advance by a word, you can combine them with your existing knowledge for much better use. So "dw" becomes delete a word, or "d3w" means delete next 3 words. "v" is also useful in conjunction with "w" / "b".
* SHIFT+V to highlight a line, `d` to delete * `:d` to delete the current line
Not experimented with `dd` (or `yy`).
You can also delete and yank multiple lines by using 'd2d' (delete two lines) or similar. You can also delete lines upwards by using a movement command like 'dk' (or 'd2k' if you want to delete the two lines above).
And I jump between enough systems that I doubt myself with stuff like: is `d1d` or `d0d` or `dd` equal?
* `:g` Global command, executes an Ex command on every line that matches via the pattern `:[range]g/pattern/cmd`
One common use I have for using `:g` is to delete all lines that match or do not match a pattern, like when I've removed an attribute from some data structure and I want to quickly fix all my mock objects to remove the attribute: `:g/pattern/d`
To delete patterns that do not match, useful for debugging: `:g!/pattern/d`
* `:norm` this thing motivated me to use more of the movement commands like `A`, `o`, `D`, `f`, `cw`, and `ci`. Used `:[range]norm cmd`, it acts like each key in the command is run on every line in range. I usually use it with a selection, for example to add a comma to the end of every line in range with `A`, or insert at the end of line: `:norm A,`
Or to delete everything after the first period in a range using `f` to move to character, `l` to move after that character, and `D` to delete everything after cursor: `:norm f.lD`
The best part about learning these two is that they can be used together. If you want to insert `fmt.Println(err)` after every line (using `o`), but only on the lines matching `err != nil`: `:g/err != nil/norm ofmt.Println(err)`
Or two write `time.Now(),` only on lines which have `"created_at":` and only after the colon: `:g/created_at/norm f:lDA time.now(),`
And if you've got hashes with string keys and string values i.e. `"key": "value"`, you can upper case the string values matching `"pattern"` with: `g/pattern/norm 3f"lvi"~` On lines it matches it finds the third double quote with `3f"` then moves a character over with `l`, visual selects inside the double quote with `vi"` and uppercases the selection with `~`.
One regex trick that I end up using with `:g` pattern matching is `^\s*`. When you put it before any pattern then the pattern matches only if it has some amount of whitespace preceding it, and that whitespace extends from the beginning of the line to the start of the pattern. It is good for targeting code indented with whitespace.
Final thought, when you're typing your commands in norm and you've entered insert mode, you can issue the escape command with <Ctrl-v><Esc> which when done right should look like `^[` but will not actually be those characters.
This is next months habbit I guess!
>To delete patterns that do not match, useful for debugging: `:g!/pattern/d`
This is something I would normally use something like grep to achieve, nice to know it exists in vim as well.
>* `:norm` this thing motivated me to use more of the movement commands like `A`, `o`, `D`, `f`, `cw`, and `ci`. Used `:[range]norm cmd`, it acts like each key in the command is run on every line in range. I usually use it with a selection, for example to add a comma to the end of every line in range with `A`, or insert at the end of line: `:norm A,`
In this specific case, I would tend to (maybe in gvim) run a replace on `\n` -> `,\n` to achieve this. That's kind of what I'm looking for in terms of string replacement.
The rest is certainly interesting, but for my work flow I like to generally keep things as simple as possible (bad memory). I've never found myself thinking "I wish there were more movement commands" for example.
All of my machines have the vim-tiny package to stay as close to stock vi as possible. I open and close the editor dozens of times a day to make simple changes and I don't tolerate any lag.
I can see that vim would be great for long-form programming but plain old vi was just fine for most admin tasks.
Plain `vi` I can't seem to work out, the shortcuts I usually use all seem to be different?
Plug 'groenewege/vim-less', { 'for': ['less']} Plug 'cakebaker/scss-syntax.vim', { 'for': ['scss'] } Plug 'othree/csscomplete.vim', { 'for': ['less', 'scss', 'css', 'vue'] }
If you are used to sed it should be easy, as it is pretty much the same. I keep using this pattern over and over again:
:%s/search/replace/gc
:% # replace in the whole file
:'<,'> # replace in the current selection
g=global to replace multiple times per line
c=confirm to let vim ask you about every replacement
> Jumping around in longer texts: I know the basics, like searching (/), jumping to a matching bracket (%) or jumping to specific lines (for line 10, type 10G), but I still could use symbols more often for navigation.
vim-sneak is real nice for this, and has turned into one of my most-used movement commands https://github.com/justinmk/vim-sneak
> Using visual mode for moving text around: Sometimes it can be quite complicated to type the right combination of letters to cut (delete) the text I want to move around. That's where visual mode (v) shines. It highlights the selected text. I should use it more often.
vim-move was a game changer for me https://github.com/matze/vim-move
> Tabs: I know how tabs work, but all the typing feels clunky. That's why I never extensively used them. Instead, I mostly use multiple terminal tabs or an IDE with Vim bindings for bigger projects.
This is worth a read: https://joshldavis.com/2014/04/05/vim-tab-madness-buffers-vs.... Buffers + vim fzf is a really nice workflow https://github.com/junegunn/fzf.vim
I like this kind of workflow because I have poor vision and selecting from a list of files, or a list of buffers is a really painful operation for me. Instead, I'm just thinking "What do I want to work on?" and type in part of the file name/path. If I forget, I can look at the list of open buffers, but it almost never happens.
One other thing I make great use of is ctags and vimgrep (just remember to use noautocmd with vimgrep so that it doesn't take a million years to parse all the files). Once I've got my working set up buffers for a problem, then it's just bouncing around inside them.
I guess what I'm trying to say is that I became more and more conservative about what external dependencies to rely on, because as soon as they become part of my workflow, I can't easily go back because they become part of muscle memory.
For vim-move I use `V` + `j,k` for the selection followed by `d` to delete and `p` for paste. Works quite well for me. The problem that I have with visual selections is, that I often want to "grow" a selection from inside of my current position. Say my cursor is inside parentheses, I'd like to hit a key repeatedly to select an ever growing region of text: first the entire content inside the parentheses, then including the parenthesis, then the entire line, then the entire function and so on. Is there a plugin for that?
Thanks for your article on buffers. Looks like a great workflow. What I'd like to have on top of that is a way to open a buffer based on the contents of a file. Say I have a file somewhere that contains a specific function, `myFunction()`. I'd love to just start typing `myFu` and vim would suggest the correct file to open. Bonus points for handling typos, e.g. `ymFu` should also work.
It allows you to repeatedly 'v' to select ever larger parts of text.
When I selected code via mouse in the past, I selected it from character to character. In vim I tend to think line-wise so I can yank, paste, delete code per line which makes sense in many scenarios.
But no, many lisp dialects have a tendency towards nesting expressions which will force them accross many lines which doesn't match up with ^^'s idea of keeping lines context free.
This is partial and patchy at best, but IMO a move in the right direction (towards affording higher levels of cognitive chunking when coding). Some languages have elements of this kind of thing working with traditional editors (eg Go Doctor for golang), and I'd ultimately prefer this less monolithic approach, but it's not really there yet.
Basically, undo trees can be persisted across vim sessions. Have a read via ":help undo-persistence".
Another one that gets commonly messed with is the search. If you use '/' then you should expect the search to begin when you press the enter key, with the usual 'n' to go to the next match. But no, some mystery .vimrc file has made this more newbie friendly, so the search happens before pressing enter. Which is not what you want if standard, expected behaviour is expected.
For reasons of teamworking I have moved away from vim plugins in the IDE, for this I have had to buy a new keyboard. Normally I do not use a full keyboard as that number block on the right hand side has no value whatsoever to me. If I was right handed and did accounts then sure, that would be a handy feature, but the number pad is really just not helping for me, most of the time, particularly on a laptop where the numpad skews the keyboard off to the left hand side. I want the spacebar in the centre, not an inch or so off skewed to one side.
So my new discovery - the gaming keyboards that have the home/end and arrow keys but no number block - I think they are called 87 key keyboards. These are great if 'moving away from vim' as the 'home/end' keys make it easy to get to a start/end of a line. Under normal circumstances with vim there is no need for these extra keys, to add to the end of a line or the start is just a matter of using the right keystroke, just 'o' or 'a' is all that is needed with the magic that is vim.
Moving away from vim is quite dangerous, for a while you find programs breaking because there is a block of 'kkjjj' or an 'i' embedded in there somewhere!
I don't actually use Vim itself very much ( I still use it for various things, but its not my main editor ). Its nicest attribute is for quick editing tasks it loads quick and can load very large files.
Maybe hjkl is a little faster than arrow keys. I don't care. I just like doing my editing with less hand movement.
I'm sure that I could perform many operations faster with a mouse. Select text, drag it a little below. Probably faster than d}}p even. The point is, mouse is finicky and annoying. The context switch between typing and moving the mouse breaks flow. Aiming the pointer is hell, and even worse if the target is small or the mouse of low quality. Anyone who plays click-heavy video games (RTS, many MMOs, 4X) can probably understand the pain of dragging the cursor between two points and clicking repeatedly.
Vim is terrible. It takes a while to learn and when you've learned it well enough you're spoiled and everything else feels painful. Vim is the closest I can get with current technology to a neurally linked brain-controlled editor. It feels like the cursor obeys my thoughts, not the limits of my manual dexterity. The next step would be an editor actually wired to my brain where I just think what the text should look like.
Tools are nice, but don't let them make you weaker.
With Vim you could split a tab with a frontend HTML and CSS file, and have a couple of backend files in another tab. Then `gt` or `gT` to switch between the groups.
If you use nerdtree, `t` opens a file in a new tab, so you don't need to type `:tabnew` often.
* Vim tends to be installed/available almost everywhere, Kakoune isn't
* Vim has a much bigger ecosystem
* There are some very advanced features hidden in vim that most people don't know about. If you depend on those, substituting vim with another editor can be hard.
[1] https://medium.com/actualize-network/how-to-learn-vim-a-four...
Sounds like he's not a touch-typist.
And as a general note; learning and mastering vim can hardly be a pleasant activity for non touch-typists, or otherwise typing heroes.
I actually use both hjkl and the arrow keys. Arrow keys are useful for moving the cursor in insert mode.
Touch typists are more comfortable with using hjkl than the arrow keys as the hjkl keys reside in the home row; so they are extremely cheaper to press than the arrow keys for touch typists.
And, you don't need to move the cursor in insert mode. vim and more generally the modal editing concept is invented just so you don't do that. I'm not sure if you are a rookie vim user or have a niche use case that requires moving the cursor in the insert mode.
I think it is funny that vim supports arrow keys at all. It's probably to reach a wider audience, and for compatibility. And a related fact is that the original vi doesn't support using arrow keys in insert mode in the way you expect.
w and b are faster because they move you horizontally between words, so pressing w 5 times will get you to the fifth "word" on a line, and b will go backwards. You only really ever use h or l after getting to the "word" you want, then going over to a letter using h and l.
I still mostly use j and k to move up or down lines
One of the things I learned was that you can do things like yank to a character. In other words, if your cursor is at the beginning of “The quick brown fox jumped over the lazy dog” you can type ‘ytx’ (Yank To to the “x” next “x” character) and it’ll yank “The quick brown fo”. That’s really handy with code, I find.
It’s full of tips on doing things “the Vim” way without plugins.
Out of the box the things I want to do are easy (multiple files, manipulating structure of blocks of text, searching and manipulating information across my project simultaneously) and the things that aren't are rare (Add a dollar sign at the beginning of the next 13 lines).
I know how to use vim solely because it's necessary to edit files in a terminal.
Easy what? Easy to learn or easy to do?
They are arguably easier to do in vim once you learn the proper method. Just not as easy to learn.
That a common trade-off shared by rather elaborate tools.
GUIs make things easy to learn and easy to do. Especially on an OS like Windows where you can drive the entire UI with just the keyboard and about a handful of well-known keyboard shortcuts.
So what's your point? Perhaps you're using a Mac or some other barely usable desktop system that has crappy keyboard acceleration for the UI?
I already said that this is a trade-off. Nobody's claiming that the vim way is the "right way" to do text editing. If you prefer a discoverable visual mechanism, you can go with it.
But some people clearly prefer to "use rote memorization" because they obviously gain something out of it.
And believe it or not, "rote memorization" is an essential part of our everyday life. Without it, you can do nothing. I don't see any harm in somebody deciding to apply it to text editing as well. Obviously thousands of people decided to do that, looking at vim's popularity.
And lastly, the memory we are talking about here is the muscle memory. You put something there once and it's done. Using vim is very much like riding a bicyle in that sense.
Would you prefer to have a bike that has labels on the pedals, brakes, gears; and prefer to go through those labels each the you need to use one of them?
Memorization allows you to do things without thinking. The mantra of vim and similar tools is to enable you to become one with the tool just like you become one with your bike, your tennis racket, your sword (!), whatever. Touch typing really helps here as well.
You can't understand that without investing enough time to that. (You don't have to. But you don't have to criticize it without really knowing what you are talking about either.)
I use Arch Linux. Keyboard accelaration is perfect.
> Would you prefer to have a bike that has labels on the pedals, brakes, gears; and prefer to go through those labels each the you need to use one of them?
That's not a really good analogy because my memory also works for GUI apps. However, I didn't have to use a rote method to get there. I just use the GUI with its labels and visuals helping me along the way. If I don't use something for a while, the labels and other visual elements are there to help me out.
> Memorization allows you to do things without thinking.
Yes and your memory works with GUIs too. But again, I didn't have to put myself through weeks of exercises to use a GUI.
> You put something there once and it's done.
I don't think so. Time is a thing and particularly with regards to lesser used features - you'll find yourself looking up things that you once knew.
> I use Arch Linux. Keyboard accelaration is perfect.
Sure it does... at least until the next update amirite?
I can understand that. It was already clear that you are not the type to give time to learn about rather elaborate tools that have higher learning curves than the average. That's ok. It may not be a part of YOUR everyday life. But not everybody is living your life.
The difference between you and me is that you are implying that vim is pointless and wrong. I'm saying that everybody should go with whatever works best for them and that every approach has their benefits.
Also, attacking my operating system has nothing to do with this discussion. Not a very effective rhetorical method.
Typically when I pose an argument in a thread like this, about a technology that I don’t prefer, it’s due to the fact that a multitude of users have badgered me over my own preferences elsewhere, saying that their technology is clearly superior.
I use Windows, Linux and Mac in that order of frequency and I like them all for different reasons and I dislike them all for different reasons. A ton of users on HN react badly to anyone who isn’t just like them. So, I was being a bit defensive sorry.
I reserve the F keys for toggles. F2 is set to pastetoggle. F3 turns numbers on and off. F4 turns special characters on and off.
I don't mean that rudely, it's just that emacs can do everything vim does & far more.
And, if I put on my snark mask for a moment, at the point you're using key chords to do your editing, why limit yourself to emacs? A fully programmable editor is now the norm, not the extraordinary.
Taking my snark mask back off, I realize there are no editors currently which are as fast an extensible as emacs yet; Atom is close, but bloated and slow in comparison.
But what I find really hilarious is that whenever these features are mentioned I see people who have been using the thing for a decade say "I never knew that!" or they dicker about what the commands actually are.