One thing google can do that blows most peoples mind when I show them: Did you know vim supports time travel undo?
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."
One of my favorite vim plugins is https://github.com/sjl/gundo.vim , which can open a pane showing the actual tree of versions, including at what time the version changed. j and k can move around in the tree, and the pane with the file will show what it was at a given time. I've definitely used it to pull out a version of a file as it existed an hour ago...
All the JetBrains IDE's keep a history of your edits, I accidentally rm -rf'd the wrong dir and reverted my code back thanks to JetBrains. I can't imagine vim saving your old files that have yet to be checked in to SVN / git (breaking changes anyone?) that you've not yet opened on vim.
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.
Vim also has persistent undo. Check out the options:
undofile
undodir
These will cause vim to store all file histories into files within that directory. Now you can close and reopen vim and continue undoing as much as you want!
Do you know if there’s a way to make “normal undo” stop at the beginning of the current session, then have some special command or confirmation that I indeed want to move further back? I almost never want to undo past the current session, but occasionally I do.
FWIW Netbeans also keeps local file history. (Nothing against Jetbrains. They seem like a great company with great products and a really nice pricing model, I just prefer Netbeans.)
Did that too, I thought history wouldn't work cause the .idea folder inside was gone, but it did. JetBrains saved me some good 5 hours of work that day.
Very cool. Do you know if you can "mark" spaces in time to jump back to like you can spatially in vim? Sometimes I change a bunch of random stuff at once to try and get something to work, and perhaps this use case would be better suited to an actual git commit but I feel like a mark in time might be a good inbetween measure.
The closest thing I'm aware of is ":earlier {N}f", which "[Goes] to older text state {N} file writes before.".
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.
I often find my self editing line x, and then add a few lines, only to find that the edit I did on line x is now needless and I want to revert only that line.
In photoshop you have an undo paintbrush. I'd love to have something similar in my text editor.
OP should consider using buffers: you can :ls to display the list of buffers (which I have mapped to gl) and then :bn (where n is a buffer number) to go to some specific buffer. Also, in the same fashion of gt and gT for tabs, I mapped gb to go to the next buffer, gB to the previous one, and g space to go to the last one. IIRC all these key bindings are unused by default. In my opinion tabs are more useful/interesting when you work with multiple windows layouts.
I use (Vim IMproved - not vi) vim all the time. I find it interesting to see what features other people tend to use in vim, there seems to be some minor differences in their workflows, but it's not clear who "wins" the productivity battle.
I 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.
That's a solid set and will take you far. I did eventually start peppering in a few pattern matching command things that don't require much regex.
* `: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.
>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.
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
The '%' is some sort of reference to the file you are currently editing and therefore you are doing a replace on the whole file. You can see the difference in combination with some visual selection. When you select some text and press ':' it opens as ":'<,'>"
:% # replace in the whole file
:'<,'> # replace in the current selection
The 'gc' flags at the end are:
g=global to replace multiple times per line
c=confirm to let vim ask you about every replacement
Sometimes its just easier to let vim ask you a few times than to spend 5 minutes to figure out the 100% correct regex.
Thank you for explaining this! I will have to practice, replace is something I don't do very often enough to remember but do it often enough that it annoys me each time.
I need to use Emacs rather than vim for some things (Proof General, mostly), and I was surprised how well evil-mode works. It's only undo that I don't get. From vim I'm used to be able to undo as many editing steps as I want. In evil-mode, I find that if I type "u" too many times, it runs out of undos to do and starts undoing the undos (i.e., it starts redoing things I want to go away).
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.
I'm guessing you mean "dd" and "yy" to delete/yank lines. "x" deletes a single character, what you mean extract a line?
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 + 'd' is a longer way of doing 'dd'. SHIFT+V + 'y' is a longer way of doing '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).
I'm also a big fan of `ci[(|'|"]` to change all the text between a pair of delimiters. I can type `ci"` while my cursor's at the start of the line, and it'll jump to the first set of double quotes, remove the text that's currently between them, and enter edit mode.
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.
Use Plug to load the plugins that you only need for a specific file. For example, this only load this plugins if I'm working wiht LESS/SCSS/CSS or Vue files :
vim-tiny differs from regular vim in how much stuff is compiled into it. Regular vim is actually quite hefty since it includes e.g. scripting bindings to Python, Perl, Lua, etc.; or support for X11 (which is useful even in a terminal for working with the X clipboard), and so on. If you have both vim and vim-tiny installed, you can use the command ":version" to compare which features have been compiled in.
Vim can be compiled as different versions, the bigger the version the more
features it will have. I know that its described in Vims manual but I can't
find it right now. Tiny versions don't include some useful features like
visual mode and tabs. My guess is that vim.tiny is made to be a drop-in
replacement for the old vi.
I know you said that you like maintaining a super minimal .vimrc, but fwiw there's a couple of plugins that really helped me with the workflow issues you mentioned struggling with:
> 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.
> 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.
> 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.
Vim buffers are great. For me the best thing is that you can go to any buffer by ":b some-unique-part-of-the-file-path". If I'm switching between a ruby file and its spec file (tests), usually I'll just have to type ":b spec" to get there. Usually I'll have 2 open windows and will just be jumping to specific buffers all the time.
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.
OP here. Thanks for the tips.
I've used vim-sneak for quite a while (it's even built into Visual Studio Code's Vim plugin), but it just didn't work with me. I'm more of an easymotion (https://github.com/easymotion/vim-easymotion) type of guy.
But even easymotion vanished from my workflow, because `/` works almost equally well for me and easymotion is not available on every system I use.
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.
Ok, I've found my easymotion replacement: I love vim-sneak! And it's justinmk, so you know it's gonna be solid. Thanks, just when I think I know the plugin landscape, someone reminds me of something new.
After using vim for a few years now, I noticed how I changed from thinking about text as characters to thinking about text as lines, which lets me create much cleaner code (independently from pretty printers).
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.
I have been noticing this effect as well, and I was thinking that there needs to be a change in how we design programming languages. The old programming languages are treating characters or words as atomic units, but human mind does not really work at words. We work at sentences or lines. Each line can have its own context and can host more flexible syntax. On one hand, the programming languages can be more expressive when designed toward line units -- lines naturally can host more vocabulary than isolated words; on the other hand, the compilers and parsers can actually be simpler or smarter, as lines pose boundary of syntax and errors may be confined and easy to recover.
Yes and no. In my experience vim is great for manipulating s-expressions because it has expressions like da( which means "delete everything between the parens wrapping the cursor".
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.
For mutating programs (as opposed to general text-editing), this text-centrism seems to me like a limitation. I use a combination of IntelliJ & emacs, and the former's deeper model of the programming language syntax definitely leads me to me thinking in terms of a syntax tree units rather than 'text', such that programming in emacs feels like going down a cognitive-abstraction step. The gap can probably be bridged with language servers (I haven't spent the time to look into what's available for the languages I use).
In general, I agree that a syntax-tree would make more sense, but I think the text centrism is some sort of greatest common denominator as that approach works for many languages (more or less). A syntax tree on the other hand, would work better but probably required some sort of training for every new language :-/
Sure, but I wasn't making a unicorn pitch. My point is that IntelliJ's relatively deep code insight nudges things in that direction right now, to an extent that makes coding in traditional editors (emacs being my favourite of these) feel a little primitive. In emacs, to change a function signature, I operate on lines of text, often across multiple files. In IntelliJ, I work on the level of the function signature, and only incidentally interact with it as 'text'.
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.
Surprised to see that he's gone back to an empty vimrc after years with high customization. To me customization is such a great part of vim that I can't imagine being without it. For instance, I have shortcuts to find and replace on visual selection. I also have at least 5 plugins in my vimrc that are absolutely necessary for my workflow. Pure vim is nice if you need to occasionally edit files, but if you use it as your prime editor its not enough without customization.
My experience has also been with a decaying amount of customization. As I get better with Vim I learn more and more how to do things in a "Vim-native" manner which I had previously needed plugins for. For example, when I first started using Vim, I relied heavily on NERDTree. These days, netrw works perfectly fine for me.
This is what I tend to hear from Emacs people too. Not an absence of cpnfiguration, just a surprisingly minimal amount because to them, the defaults start making sense. I have no idea if this is because the human learns the editor, or if it is the editor shaping the thoughts of the human, but it sounds nice and I sort of wish I would get there soon.
I think it needs some customization for full-time use too. Example: you can toggle comments with things like `:norm i// ` and `:norm 03x`, but with nerdcommenter, you just type `gc` or `gcu`, which requires less attention.
One current problem I have with Vim is those linux distributions where someone - maybe the VPS vendor/hosting company - put in some mystery .vimrc file somewhere that makes the editor apparently more friendly for new users. So you copy and paste a line to your mysql config file, to restart the database service and find that nothing has changed. So then you edit the file again and discover that the mystery .vimrc file has added a '#' at the start of the line.
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!
The point in the article is that the Vim keyboard bindings are most useful. Most editors have an option or plugin for that. That's what I use mainly. For instance I use Visual Studio + Resharper + VsVim ( + AceJump + RelativeLineNumbers) as my main development enviroment. I also use webstorm configured in a similar fashion. Visual Studio and R# understands the code and how to manipulate code far better than anything in the Vim world does, but I use it in combo with Vim keyboard bindings and it becomes incredibly quick to do things.
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.
Vim user here. One thing I rarely see discussed is the idea that vim is not about speed. It's about comfort.
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.
One thing I noticed when working with people who are only familiar with IDEs for coding and GUIs for version control: they're helpless on remote servers. If they need to jump on a box and debug an issue live, they just can't do it. For me, using tmux + vim + git cli locally, my workflow remains exactly the same remotely.
Tools are nice, but don't let them make you weaker.
Tabs are great for organizing groups of related files. They are different from other editors that only let you have one file per tab.
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.
Nowadays, I prefer Kakoune ( http://kakoune.org/ ) to vim. Being based on selections rather than movements feels much nicer. It feels a bit like always being in a kind of visual mode. That said, there are the following caveats:
* 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.
Some of the keys match up, but many are different. The actual way of thinking and composing actions while you're editing is similar, although I'd say thinking in terms of selections rather than movements makes things easier.
I ran 'vimtutor' twice and felt comfortable enough to switch. I think the only reason people think it's so difficult is they maybe try to go too deep too fast?
I repeated vimtutor for a few days in a row trying to following this nice Vim learning plan [1] I saw on HN and I gave up trying to switch to Vim as my main text editor after that. Even though I knew how to perform most of the basic operations, the fact I had to switch to normal mode to do anything more complex than editing of the current line felt just too unusual to me. I mean, I'm comfortable editing files on remote servers in Vim now but I don't think I'd ever be considerably more productive in Vim than in IntelliJ/Sublime.
> I don't use arrow keys to move around in text anymore but forced myself to use h, j, k, l. Many people say that this is faster. After trying this for a few years, I don't think that is true (at least for me). I now just stick to it out of habit.
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.
Because the hjkl key bindings are invented by touch typists for touch typists.
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.
The best tip i had when using vim is to almost never actually use h or l.
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
hjkl by themselves are probablly not a lot faster than arrow keys, after watching various people code in Vim on twitch, I notice quite a few use them like arrow keys to arrow to where they want. But it's how hjkl combo with other motions that makes getting around easy. Though I really like easymotion ( and derivitives ) for getting around to random places
OP here. I'm a touch typist. Not the fastest, but I can type around 70wpm with ten-finger-system.
Still think the movement between the home-row and the arrow keys is not a big deal, at least in my workflow.
I actually mostly use w and b instead of h and l because it's faster.
I read an article a few years ago, the name of which escapes me. It was something like “Idiomatic Vim” or “Linguistic Vim”. I would love to find that article again, if anyone happens to know based on the sparse info I’ve just provided, I would greatly appreciate it.
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.
All of the points in the "Some things I wish I could do better" section are the reason I use a regular memorization free-ish IDE.
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.
Yeah "once you learn the proper method" is the key phrase here. The proper method being "use rote memorization to learn about things which could have easily been made available via some discoverable visual mechanism".
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?
> The proper method being "use rote memorization to learn about things which could have easily been made available via some discoverable visual mechanism"
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.
Define rote: mechanical or habitual repetition of something to be learned. This is not something that is part of every day life at all. After school the only time I had to repeat something over and over with any kind of frequency at all was when I was learning vim.
> 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?
> Define rote: mechanical or habitual repetition of something to be learned. This is not something that is part of every day life at all.
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.
I agree that everybody should use what works best for them. So there’s definitely value in that.
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.
Regarding tabs: I bound F2 to previous tab, F3 to next tab and F4 to new tab.
Besides highlighting the current line, I think this is my most important customisation.
Since I rarely do window splits, I finally gave up on tabs and just stick with buffers. Tabs in vim aren't really tabs anyway. They are window layouts. If one tries to treat them like tabs, things can get confusing fast. Using Airline, you can show your buffers in a line at the top of the screen and treat them like tabs, which is nice. I map <leader>h and <leader>l to move between buffers.
I went a slightly different direction. CTRL+N is next buffer (ie: tab), CTRL+P prev buffer, LEADER+W for close buffer. I don't make new buffers a lot, so I just type out :new when I need to. Opening an existing file is LEADER+F, which opens fzy via vim-picker.
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.
To paraphrase the OP's own words, he likes vim because it treats editing as a first class citizen. Editing in emacs, without something like evil mode, is a second class citizen - it requires key chords to do.
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.
Whenever vim comes up I see someone trying to sell the audience on some "amazing", obscure and rarely used feature that users of other editors should be jealous of... However, it seems to me that if anyone actually wanted those features then they'd be standard in other text editors and we'd have them already.
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.
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."
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.
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.
In photoshop you have an undo paintbrush. I'd love to have something similar in my text editor.
https://github.com/pera/vim/blob/master/.vimrc
I 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.
* `: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.
http://vim.wikia.com/wiki/Power_of_g
>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.
This is next months habbit I guess!
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:
The '%' is some sort of reference to the file you are currently editing and therefore you are doing a replace on the whole file. You can see the difference in combination with some visual selection. When you select some text and press ':' it opens as ":'<,'>" The 'gc' flags at the end are: Sometimes its just easier to let vim ask you a few times than to spend 5 minutes to figure out the 100% correct regex.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:
For more information, please see: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?
http://github.com/tpope/vim-surround
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.
Plug 'groenewege/vim-less', { 'for': ['less']} Plug 'cakebaker/scss-syntax.vim', { 'for': ['scss'] } Plug 'othree/csscomplete.vim', { 'for': ['less', 'scss', 'css', 'vue'] }
Plain `vi` I can't seem to work out, the shortcuts I usually use all seem to be different?
> 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".
[1] https://github.com/mbbill/undotree
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.
https://gist.github.com/nifl/1178878
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.