Man, I'm pretty convinced that Vim macros have single-handedly saved me years of my life. They're so incredibly useful that it's made Vim one of the first things that I install on any machine.
Same with Emacs keyboard macros. I use them very often to do similar things to many lines. Usually they involve some combination of search to move the cursor, word-based movement, cut and paste, and insertion. It's such a great feeling to define a one off macro in a few seconds and then rip through a whole file!
If you use emacs keyboard macros regularly and find yourself ever re-recording them because you messed them up just a little bit, try out `C-x C-k C-e` (kmacro-edit-macro) sometime. It's life-changing.
Am I missing out by not learning Vim? I know enough to get by for git purposes (renaming all picks to s is amazing), but I feel like I'm really productive with Webstorm. There's a ton of great shortcuts and great features (multi-cursoring, intelligent refactoring, customizable search directories, integrated terminal, etc.) that I feel outplay anything I could do with Vim.
Webstorm (and all IDEA-family IDEs, as well as most IDEs in general) has a fantastic Vim plugin that allows you to use vim bindings within the text-editor of the IDE. That's what I use and it saves me so much pain.
FWIW as a 'real vim' user I typically find these plugins severely lacking.
For instance, I've recently tried the ones in Atom and VSCode and they were both incompatible with my normal workflow. In one of them you couldn't save files with :q, for instance.
They're works in progress, likely--and I'm still grateful to the teams who work on them. They just weren't enough for me.
I completely agree. Perhaps things have changed for some of these plugins since I last tried them, but the only one that has not only basically matched Vim but exceeded it is Evil for Emacs.
I've found the IDEA Vim plugin to be good enough for most of my work, but the macro support isn't great. Specifically, I miss running macros on multiple lines with `:norm@q`.
The Jetbrains plugin is really good. So far I've found that it covers everything I use. Saving is not an issue with Idea since it autosaves and keeps a local history of your changes as you work.
I initially wrote it for a couple of Windows sysadmin friends at their request. They had been given a few Unix machines to manage. They said it helped them quickly get up to speed with the basics of vi. I later published it as an article in Linux For You, a print computer magazine (now Open Source For You).
No. I used vim for half a year and then went back to notepad++ and similar for plain editing. The bottleneck in programming is thinking anyway, and not typing. It does not make a difference. For serious coding, I recommend a serious IDE.
Any that don't suck at windowing? They all want to show only one, or at best two files at a time. They're primitive compared to the windowing capabilities of vim/emacs/tmux.
No, not really... prior to 2017, that was one of my biggest gripes with Visual Studio - opening multiple editor windows in one instance would quickly chew up enough memory to hit the 32-bit process limit and start page thrashing. Why, I have no idea, but that's what I've seen consistently the past few years in VS 2013 & 2015.
Does it do better now? Can you have 12 windows arranged at once? If so, please tell me how because I spend most of my day in VS. but time and time again I need to open shit in vim, just to get a clear overview.
Far as i know, no. I was settling for having 2-3 editor windows open at once. 2015 was such a pig I avoided it. 2017 can handle it so far. I wouldn't bet on big solutions 100k+ lines of code though.
multiple cursors: is nothing compared to the confirm flag in `:%s/foo/bar/gc` + columnar editing in conjunction w/ something like tabularize
intelligent refactoring: is extremely unlikely to happen soon
customizble search directories: is way more flexible in a terminal than anything i've ever seen an IDE guru do. it's not vim though. it's vim + shell.
integrated terminal: you're already in the terminal, using tmux doubles down on the benefit
vim has way more flexible buffer pane layouts + tabs + sessions (IDE's also have sessions, but vim can do multiple sessions for a project). i've never seen an IDE with anything like the jump stack, marks, multiple yank registers, the flexibility of macros, or anything like `:r !$COMMAND` or for that matter `:w !$COMMAND`. basically no IDE has anything which matches vim's `NormalMode`. type aware code completion and syntax checking is available depending on the language.
these things aren't free though. you have to invest before they pay out.
> multiple cursors: is nothing compared to the confirm flag in `:%s/foo/bar/gc`
Why is that? I'm a long term vim user, and I prefer multiple cursors to 's///gc' for many operations. Unfortunately the multiple-cursors implementation (via plugins) is not flawless, but it's quite handy for standard usage.
`gc` makes it much more flexible and faster if i know i have a small number of "exceptional" matches, especially early in a buffer since it offers you `y/n/a/q`. i also find it much faster than clicking potentially dozens of places in the code vs spewing `$ROUGH_REGEX` then mashing `yyyynnyyyna` to make edits in 70 locations.
Depends a lot on the work that you have to do I guess. I can spend a lot of time on remote systems, so learning a powerful editor that I can rely on to be there was useful. And all linuxes usually have vi or vim.
But if you don't do that sort of thing, there are plenty of other tools that you can use. Most are probably far easier than learn vi.
But I like using command line tools where possible. Most are available everywhere and they are incredibly powerful once you learn parts of them.
vim, like emacs, is a programmable text editor. Maybe $your_favorite_ide totally outplays vim (or emacs) at some feature, or maybe someone has written a plugin that has an equivalent (or better, or somewhat worse but acceptable) version of the feature, you'd have to look if that's your main criteria. But also note there are many plugins that don't exist in other editors, and of course for vim there's the various macros/functions/key maps that exist in users' memory or .vimrc files that they wrote themselves or got somewhere that solve all sorts of tasks, general and specific. Anyway, being programmable, you don't have to wish the makers of the editor made some feature you saw in some other editor, you can just program it (or convince someone in the community to do so), plus there's all the various tasks of text editing that really benefit from being able to automate something this one time. If you don't care about programmability of your editor, you're probably not missing anything.
The JetBrains apps actually have a very good Vim plugin, so you could really get the best of both worlds.
I view Vim as half-editor, half-editing philosophy. The editor is just an app that I like, but I feel that embracing the philosophy does make me more productive and able to accomplish a lot.
I had a recent refactor which was basically "take a 5-argument function call split over many lines and replace it with a different 1-argument call". I made a macro that found the code block I wanted, edited it to the desired syntax, saved the file, and opened the next file in the list I had opened. I opened vim for this occasion with `vim $(ag -l STRING_IN_REFACTORED_CODE)`, which used search results as a list of files to open with vim.
The most fun vim macro I've made solved a "solve this puzzle before we want to interview you" question. The problem was a URL to request that gave you a response to parse into the next URL, chained about 100 times. The vim macro took the URL in the current line, shelled out to make a network request for the result of `curl` with that line as an argument, and edited the result into the next URL to fetch.
A very common thing that happens to me is that I have to take big blocks of JSON, and map all the keys and values into something else, like HTML or CSV.
Without macros, this traditionally involves a lot of copy-paste-change-stuff repetition.
With a Vim macro, I can happily just do this once, assign it to a register, and repeat as needed, and even store it for later reuse if I want.
There are also, littler things, like jumping between HTML tags, or bulk-indents.
What makes Vim's macros better (in my opinion) that other editor's macros is that fact that they're simply stored in copy-paste registers, meaning that you can have many of them, store in a different file, copy them off the internet, or compose them together.
Not op but here they are really handy for creating and formatting repetitive code blocks. I find it particular useful when making testing\throwaway code.
For example, I may be testing a function and wanting to test a few scenarios on many IDs. So I will create a csv list of numbers and then use a macro to format it
your csv string will be like this (normally much longer)
134,234,367,4345
Then record the macro:
- type "myFunction("
- type ctrl + right arrow (this moves the cursor to after the comma)
- type backspace
- type ");"
- type enter key
then run stop recording and run the macro. It will produce:
myFunction(134);
myFunction(234);
myFunction(367);
myFunction(4345);
Which doesn't seem like a big time saver over regular copy and pasting. And you could have iterated over the csv string with a for loop. This is probably a really contrived and basic example but you find yourself thinking about using a macro anytime you have to do the same keystrokes over and over.
My favorite use of macros is as a sort of progressive global search and replace on steroids. I have @q bound to Space, so I can record a macro with qq, then hit space to repeat. Since the macro is just a list of commands in a register I can copy it out and edit it to tweak it, once I'm happy with it over a few lines I can make it recursive by adding @q to the end of it.
Compared to regex search and replace this is much more malleable, interactive, and ultimately powerful.
It's worth remembering that . (i.e. dot) repeats the last edit command. vim-repeat ( https://github.com/tpope/vim-repeat ) makes this even better.
Although, there are still several situations where macros are better, especially things that involve several motions and edits. (I tend to use qw because w is more convenient to hit after @).
Also, it's occasionally useful to remember that you can use the double quote character " to paste a macro, edit it and then update it. i.e. ( "ep .... edit ... ^"ed$ )
Also, vim-surround is one of those things that, once you've used it for a while, it's impossible to think of editing text without it: https://github.com/tpope/vim-surround
Somewhere between the default and your binding: @@ repeats the last macro. So you can record your macro, go to your search text, @q, n, then for all subsequent matches @@.
A common one is "here's an excel file, can you put these entries in the database". With macros it's easy to do a really complex transform of a line and then repeat it for every line.
Or the reverse, someone wants a report from some database in some specific format for whatever reason. It's often easier to do a simply query and vim the output rather than use the string functions of the DB.
yes, you are missing out, but not because you HAVE to use Vim, but just because Vims approach is quite different it's worth learning so your mind at leat knows about this whole other approach to editing.
I find Vim plugins in most editors are quite good, a true vimer probably doesn't like them as much because they are a blend (but then, they may as well just use Vim itsefl), and for jetbrains stuff, it blends the awesome of vim with the awesome of jetbrains code manipulations.
My last macro took about 12 seconds. Really complicated ones can take a while if you have very conceptually-heterogenous text structures, but it's literally "start macro + do stuff + finsh macro" -> use macro.
