Editor Wars: The Revenge Of Vim

Rarely on these pages have I read such a fluff piece! Al Williams’ coverage of Emacs versus Vim was an affront to the type of in-depth coverage our Hackaday readers deserve. While attempting to be “impartial” he gave a seven-sentence summary of Vim, the Ultimate Editor. Seven sentences! Steam is pouring out of my ears like Yosemite Sam.

yosemite+samAl, like a lot of you out there, thinks that he “knows how to use vi”. I’m here to tell you that he doesn’t. And unless you’ve spent the last few years alone in a cave high in the Himalayas, with only food, drink, a laptop, and Vim Golf, you probably don’t either. Heck, I don’t consider myself a Vim master, but I’m going to write this overwrought essay praising it (using Vim, naturally).

The reason I’m writing this is not to perpetuate the vi-versus-Emacs war. That idea is silly anyway, and was probably invented by Emacs folks to steal some of vi’s limelight. You see, vi-versus-Emacs is a red herring. Vi and Vim are so strange, so different from any other editor you might use, that it makes Emacs look simply boring in comparison: it’s just a normal editor with decent extensibility (if you can stand Lisp), horrible key combinations that may or may not cause carpal tunnel syndrome, and code bloat that rivals Microsoft Word. If you’re comfortable using Pico or Nano or Joe or Notepad++ or Gedit or Kate, or anything else for that matter, you can be comfortable using Emacs in a month or so. It’s really just another editor. Yawn.

Vi is something else. It’s a programming language for editing text that’s disguised as an editor. If you try to use it like a normal text editor, you will suffer. If you approach your text editing chores like factoring code into functions, you’re starting to understand Vi.

Modes and Movements

vim-shortcutsAs Al pointed out, vi and Vim (henceforth Vim, because it’s got some neat extras that I really miss in plain-old vi) use the concept of modes. There’s “insert mode” where you type text. In a normal editor, you’re always in insert mode. When editing in Vim, most of your time is spent in “normal mode” where your keystrokes are like commands, moving the cursor around, cutting, pasting, finding, replacing, crafting macros, changing one HTML tag to another, and generally editing. This distinction between typing and editing is central to Vim’s philosophy, and they’re fundamentally different activities.

When you start up Vim, it tells you to type :help and work through a tutorial telling you how to move the cursor around. You should go do that — that’s what it’s there for. It’s not going to make you a master, but you’re going to learn the basics. Do not go around saying that you “know how to use Vim” at this point. You’ll just look silly. You will know how to move the cursor around, cut and paste, and enter and edit text. In short, you’ll be editing like a monkey you would in Emacs.

Programming Text Editing

The real secret of Vim is that normal-mode usage is a language somewhere between a human language and a programming language. It’s got verbs, adjectives, and nouns (or functions, modifiers, and objects). Your job is to figure out how to express your text editing desires in terms of these, mostly single character, commands.

Let’s take c, the command that “changes” some text. By itself it does nothing — it needs an object. But if you type caw (“change a word”), the word under your cursor gets deleted and Vim enters insert mode, waiting for you to type the word’s replacement and hit Escape to go back to normal mode. If you want to change a whole sentence, cas deletes it and you’re typing anew. Want to change all arguments of a C function inside parentheses? ci) “changes inside parentheses”. (ca) deletes the entire thing, parentheses and all.) Numbers fit in as well. If you want to change the next five words, c5w does what you want. The syntax is modular and extensible. In this sense, it’s easy to learn.

the-shining-3_7-movie-clip-all-work-and-no-play-1980-hd-4lq_mju4qhwmp4-shot0001Cute trick. But here’s the punchline: .. Period repeats the last editing action as a whole unit. So if you just changed a word to “Hackaday” and returned to normal mode, cawHackaday<Esc>, and you have the cursor over another word, typing . turns it into “Hackaday” as well. Tossing a movement command into the mix, w will move the cursor to the start of the next word. Now, alternating . and w will change every word in your document to “Hackaday”. Using only two keys. Think about how much more efficiently Jack Nicholson could have appeared crazy in “The Shining” if he had Vim and the . command.

That doesn’t sound useful, but think about how many times you refactor code by changing all functions named “foo()” to “getFooInstantanceMethod()”. Of course there’s a “normal” search and replace functionality in Vim, but most of the time you don’t actually need it. Why? Because /foo searches for “foo” andcaw will then change the word under the cursor. And the search, being a movement, is repeatable with ;. Alternating ; and . becomes the same as a search and replace, only both the search and replace parts are (nearly) arbitrary editing actions. Instead of typing “y” and “n” to change or not change each match, you just hit ; until you get where you want to be, and then type ..

There’s so much to say on this topic that it’s the classic off-topic question at StackOverflow. The point of Vim is that text writing (in insert mode) is just typing and there’s not much that the editor can do for you there. Text editing, on the other hand (in normal mode), often consists of repetitive actions. Vim is built around treating these actions as single units and making it easy to repeat them and link them together. If you’re a programmer, this sounds a lot like the activity that we call programming — breaking a big task down into functions and running them. If you understand coding, you can learn to understand Vim.

Visual and Command Modes

There are actually a few more modes that you’ll want to know on your path to Vim mastery. Visual mode lets you select a region of text first and then apply a command to it second. It’s useful for one-offs, but visual-mode selections are hard to translate into generalizable functions, so I don’t use it as much as I used to when I was learning. There are some useful plugins that make good use of visual mode, however.

Command mode is where the real Vim heads geek out. It’s essentially ed, the ancient line editor. :17,25d deletes lines 17 through 25 without moving the cursor. :-3t. copies the line three above the current one. :v/foobar/s/thang/thing/g changes “thang” to “thing” in all lines of the document that don’t contain “foobar”. This is also where you can use all that regular expression juju you’ve got stored in your grey matter.

On the other hand, simple things like global search and replace, and deleting or copying whole lines are also simple on the command line. %s/one/two/gc changes all occurrences of “one” to “two”, with confirmation — your standard search and replace. (% specifies the whole document. You can use line-number ranges here too.) And of course there’s :e which opens a file for editing, and :wq which saves the current file and quits. You don’t need to know much of the command line mode commands, but a few are fantastically useful.

Registers and Macros

After a while, you’ll want to understand the registers. Vim stores text (or commands) in registers — like variables in a programming language. You can cut and paste into or out of the registers, and the first ten of them are essentially a cut buffer. The registers make a great place to store text that you’re cutting out now, but not sure that you want to throw away yet. "zdi} will delete all the code inside function brackets but save it in register “z”. You can paste it back at any time with "zp. Want to paste that thing you deleted five deletions ago? Type :reg to see all the registers and their values.

You can also record and play back series of Vim commands into the registers like macros; Vim commands are mostly just letters, after all. q starts and ends a macro recording, so qw will record a macro into register “w”. You can play it back later with @w. Macros are, of course, as powerful as the person writing them. (And yes, the registers plus the text buffer is Turing complete. Don’t go overboard.) I only use a few macros, but those that I do use, I use all the time.

For instance, here’s a macro I use a million times a day. I write Hackaday posts in Markdown and then compile them into HTML for posting. A link in Markdown looks like this: [link text](https://www.example.com). S]f]a(<Esc>"+pa)<Esc> surrounds the currently selected text in a “[]” pair, finds the closing “]”, adds an open parenthesis, leaves insert mode, pastes the contents of the clipboard, adds a closing parenthesis, and goes back to normal mode. (Yeah, that took me a while to get working.) But now, I copy a link in the browser, select text and type @l in Vim, and I’ve got a Markdown link to that website.


Like any editor worth its bits, Vim is also incredibly extensible, and if there’s any feature that can’t be macroed, one can always write a plugin for it. In my opinion, Vimscript is even more unpleasant to write in than Lisp, so I leave extension writing to other folks. Someone’s written a module already for nearly everything you’d want anyway. But don’t go hog-wild with plugins in the beginning. You’ve already got your work cut out for you just learning Vim.

When you do succumb to install a bunch of plugins, my advice is to add them one at a time and use it until you understand each intimitely. Here’s what I run, in a reasonable order to install and learn them: vim-sensible, vim-airline, vim-abolish, ctrlp.vim, UltiSnips, vim-surround, vim-easy-align.

The Best Vim Commands

If you already use Vim, but don’t use the following commands to their fullest, you’re not living right.

  • I and A insert and append text to the front of the line or the end, respectively.
  •  m and “` set marks and jump back to them. This is invaluable for leaping around a long document with ease.
  • g; goes back to the location of the last edit. This is “pick up where I left off before going somewhere else”. It’s gold. But that’s not all — it keeps track of your edit history so that you can go back five edits ago. And g, moves you back forward in the edit history.
  • CTRL-] jumps to the location of the definition of the function under the cursor, and CTRL-t gets you back. Go as deep as you want — hitting CTRL-t until it doesn’t work anymore will get you back where you started. (You’ll need a tags file to make this work.) This is fully 1/2 of the value of an IDE like Eclipse for me, built in, with less screen clutter.
  • The other half of an IDE is tab-completion of long variable or function names. This is done in Vim with CTRL-n and CTRL-p to scroll up and down the possible list. If you are using a tags file, or if you have the file with the other definitions open in Vim, it will complete the name for you.
  • gg=G jumps to the top of the document (gg) and auto-indents it (=) until the end of the document (G). This makes all your open and close braces line up, and makes it very easy to spot the one that you forgot.
  • u undoes the last command. CTRL-r redoes. :earlier 2m reverts to the state that it was two minutes ago. If you end up undoing, editing, and then want to undo some previous changes, you can. g+ and g- will step up and down the undo tree. It gets complicated.
  • / and f, the search commands, are vital as a motion in a compound command. df, deletes everything up to the first comma. d/foo lets you delete until the first (interactive) match on “foo”. This can replace many other movements if you’re so inclined.
  • :r reads in a file. :! runs a command in the shell. :r! pastes the output of a command into your document. :r!ls whatever* is often faster than typing in a filename. I’m not going to get started on how UNIXy the ability to run your text through arbitrary shell scripts is.

Vi Everywhere!

Once you get used to Vim’s movement commands, you’re pretty much spoiled forever. You can of course use the mouse, but when you get good, you’ll only do so rarely. It’s so much faster to keep your hands on the keys. Most every hardcore Vim user remaps the Escape key (which returns to normal mode) to something convenient. Mine is where Caps Lock used to be, right under my left pinkie. (I actually multiplex it with Control using xcape.) Yeah, that’s extreme, but it’s so much better than what people do to avoid getting carpal tunnel from Emacs which was designed to work on a keyboard that doesn’t really exist anymore.

If you use Bash shell on a Unix, set -o vi will make readline behave almost like vi. Your browser can be Vimmified: Vimperator and Pentadactyl for Firefox or cVim, vimium, and ViChrome for Chrome should do the trick. If you want to go all-out, qutebrowser is the best native Vim-style browser out there at the moment, and it’s going to get much better soon.

Search “vi keybindings” and you’ll find that they’re supported in everything from Visual Studio to Eclipse to Emacs. Why does Emacs have a Vi-emulation mode, but Vim doesn’t have an Emacs emulation mode? Think about that for a while, and you’ll realize that the editor wars have been won.

Getting used to Vim takes a while. Getting really good takes a programmer’s mindset and some active practice. I used Emacs from 1994 to 2011 for code, my dissertation, overheads for classes I taught, and academic papers. Since 2011, I’ve used Vim for yet more code, a book, e-mail, and all my writing for Hackaday. I can still improve, and I add new tricks to my repertoire monthly despite five years of using it for six to eight hours per day. Vim is deep, like anything that’s really worth diving into, but it’s rewarding because there’s always more. Don’t believe anyone who tells you that they “know” Vim. :wq.


There’s really too much to say about Vim. Here’s a short list of great resources:

124 thoughts on “Editor Wars: The Revenge Of Vim

    1. Auto hotkey, notepad++. What else do you need? I do 99% of my programming tasks with these two programs. I can bang out code on vi or nano if there is no external file access, or I just need to change a line or two. Other than that no need unless you are used to the nostalgic feel.

      1. You can do programming tasks just fine with those things, but you aren’t really addressing any of the points made in the article. Modal editing, text objects, the composability of the various mnemonic commands, line editing from ex, the great help documentation, and (not necessary, but very nice) all the plugins. It’s a never-ending journey of improvement and the occasional “ooh, I didn’t know about that!”.

        Don’t knock it until you try it.

  1. I know how to do a few things in vi: insert, append, delete char, delete line, quit and exit(with write). It’s easy to use and does what I need to do 95% of the time.

    emacs, on the other hand…

    1. Ditto, and it’s served me well for nigh on 30 years. By intentionally limiting my actions, I’m much more able to cope with any editor the OS/ide/whatever throws at me. Chuck in a bit of sed and grep, and there’s nothing more I need.

  2. vi/vim survival commands for me are: i, A, (to go into insert mode), ESC (…to exit it), : (to go to command), w (write to disk), q (quit and q! to quit enforce / w/o save changes), x (to delete char), and dd (delete a line). If I need to do more than just minor (config and properties file) edit, I resort to an GUI IDE where I do not need learn another language doing things…). May be I lived in the Himalayans since early 80 when I minted this survival into my brain. I know that there are many other great commands… to increase efficiency, and I like that lesser stress on my eyes than GUIs impose… ;-)

  3. Glad to see this piece. I am an old die hard vi dude. I won’t call myself a vim dude because I have barely scratched the surface with all the features that are in vim. I keep telling myself I should invest a day or two and “sharpen my tools” by learning new tricks. Just putting the cursor on a word and using “*” to search for more of the same word was a revelation. I have a book “Practical Vim” by Drew Neil that seems quite good; I should spend some time with it. If people want to use emacs that is fine, but using emacs is getting to be an old school “retro” thing that earns bragging rights in certain circles more than a superior way to get work done.

    For someone like me who can use vi instinctively there is absolutely no reason to switch to emacs. For someone who knows neither editor it is a different question. Vim seems to have a lot more momentum these days, and I would promote it for that reason alone (is that unbiased enough?)

  4. Ew emacs shortcuts.

    Tough if you want to use bash interactively (or any GNU readline prompt including but not limited to bc, ftp, gnuplot, gpg, ksh, mysql, psql, python, smbclient, xmllint and zsh) effectively you need to learn them.

    Learn to use vim, and that’s all you can do.

    Learn to use emacs and you become a pro on all those programs and probably any GNU program which has a prompt or interactive mode.

      1. Yes indeed. ‘set -o vi’ is a permanent part of my .bashrc and a command I type almost immediately after I get on a new system. You get pretty spoiled by command line editing using the keystrokes wired into your brain. I want to solve problems and have my fingers fly on autopilot.

      2. Yet another reason why emacs is better. It includes vi emulation.

        Vi is the bare bones you need to get something running in a pinch. Emacs is the lush full featured software when you want comfort.

        People learn to use emacs to be productive. People learn vim for the same reason they wear cilices.

          1. How true.

            You can (almost) always count on finding vi on a system. The few necessary commands are easy to memorize, and that’s all you need to fix a broken system.

            emacs, with the proper key combos, will probably regenerate and recompile the system for you, if you could only remember whether it’s C-M-A-x or C-M-x…one reformats the HDD and the other rebuilds the system :-)

        1. (Opinion-time here) Vim is a better editor. It has commands that are _specifically designed_ for editing text, and they’re short and easy to type. It is also harder to learn by a lot, leaving many people stuck with less-good editors.

          It’s probably no big deal. But the “vi is minimal — in a pinch” argument is wrong, IMO. I have tons of hard drive space, and both Emacs and Vim installed. I have tons more experience with Emacs. I run Vim.

          Features: they are approximately the same. There are no killer features of either that the other doesn’t have.

          But I’ll give you the comfort argument. But then, why not go to Kate or Gedit or Eclipse, or something modern and significantly more comfortable? Because you can’t write your config file in Lisp? Please. That’s not comfort.

          Emacs used to have a niche. It’s overgrown with better options now. Vi/Vim is still king of its market — text and code editing where a learning curve is not an issue.

          1. > But I’ll give you the comfort argument. But then, why not go to Kate or Gedit or Eclipse

            Emacs primary benefit is it runs just as well (imo better) in a terminal.

            Emacs shallow learning curve means you don’t loose much from beginning to use it. Most beginners are no worse off than with Kate/Gedit for the first morning and are already more productive by evening.

            “learning curve” is not an issue. Learning curve is always an issue because until you conquer the main slope you are less productive not more productive.

            The speed at which I got proficient with Emacs was phenomenal. Want to ease this mild learning curve? Use it in window mode with mouse support.

            You have the perfect play ground to work on your Emacs skills, while they guy next to you struggles getting his head around vim.

            As you rightly say, no one has ever really been held back because they are a vim user or a emacs user.

            But they probably were held back trying to get their head around vim.

            Learn to think about writing like a programmer? We’ll all programmers anyways… At least Emacs teaches you lisp if you want to specialise.

          2. Just in case people are wondering. Lisp is not just another programming lanaguge.

            It is a genuinely interesting programming language which it one of the oldest which sees use.

            IMO programming languages have value in their utility (I need to know C to program low-level efficiently on microcontrollers) or something less tangible in that they change the way you see the world (Haskell, Verilog).

            And Lisp mainly in the second category but also does have legitimate uses I don’t want to belittle as well as letting you configure emacs.

            When you write some really good Lisp you feel more like you extended Lisp to solve the program.

  5. Enjoyed the article. But:

    > Why does Emacs have a Vi-emulation mode, but Vim doesn’t have an Emacs emulation mode?
    > Think about that for a while, and you’ll realize that the editor wars have been won.

    Sounds like Emacs has already won to me. Emacs can do what Vim does and _oh so much_ more.

    1. Vile is actually just like Vim, only much less! No plugins, none of the new goodness that’s come along in recent versions of Vim, etc. In short, it’s like crippled Vim.

      Does anyone use Vile? I know two people who said they did, years ago, and now both use Vim.

    2. I liked the article as well, I agree but Emacs can do more, however you don’t edit in Emacs like you do in Vim, I tried to learn Emacs after using Vim for more than a decade and really liked it, but the first think I did after knowing the basics was installing evil-mode, you can’t beat Vim for power editing

    1. I wonder about Nano. What little reading I have done indicates that is has a kinder learning curve for new users, but is limiting for serious use. In other words it is great if you just have casual need for an editor, but if you plan to spend 95 percent of your time in an editor (as us software dudes do), then you are well served by biting the bullet and learning vim or emacs. I’ve been using vi since 1983 or so, maybe before that, discovering it on Unix edition 7 on the good old Interdata 8/32. Given that vim versus emacs is mostly a matter of taste, I guess I’ll stick with it. I have enough other learning curves to climb.

      1. Horribly inaccurate. As someone that has been spending 95 percent of my time in an editor writing code and editing systems exclusively with nano for the last 15 years, I can assure you there is no limitations that you will be running into that you need a big bloated piece of crap like emacs or the cryptic hipster editor vim. Simplicity and speed is what you get using nano/pico, if you want to jerk your keyboard off all day typing in pointless commands switching back and forth between jerking your editor off and getting something done then yes vim is definitely for you, if you want to actually get work done then pass on the two bloated contestants and look at the real winner.

    2. Yep. I look at all the stuff it’s possible to do in Vi(m), and it seem to me that it’s quicker for me to do it the long way round in nano, rather than the time it would take me to learn how to do it the quick way in vim.
      Of course, if I need to do real work with text I’ll use Notepad++ ;)

      1. lolz!
        I have noticed that also, and been reprimanded by my system at compilation or interpretation time.
        I also have to admit that some of my html has sported the “:w”, accidentally!

  6. Why bother to learn VIM or EMACS with modern days graphical environments. Who care about bloated software when there is plenty of RAM and MCU power available. IDE have their key binding too, and some editors have macro recorder, or macro language.

    the fact is majority won’t learn VIM or EMACS. I only knows the basic of VIM and use it as a last resource.

    1. Honestly? Cool factor. No not really.

      I use VIM because a lot of my early use of it was over SSH, where an IDE is impractical at best, nigh on impossible at worst. I learned to use VIM to get things done quickly and easily. It became second nature to me, so when I started to develop software, I fell back to VIM because it was comfortable.

      Now, I have a fully customized development environment that rivals (or in my opinion exceeds) most IDEs in functionality. My dev setup consists of GNU Screen (trying out tmux, but a little iffy with it so far), Vim + a buttload of plugins, a hand full of Bash scripts, and the compiler/interpreter of choice for the given language.

      It may not work for someone else, but works for me, and makes me more productive, since I don’t have to learn a new IDE for every language.

    2. I’m thinking the same thing. I mostly use Python with PyCharm, when I look at VIM and I need a tutorial just to learn how to move the cursor around I just don’t get why anyone would put their self through that lol.

    3. How long does it take your IDE to start up? How about open a new file (or project)? When your JTAG debugger crashes do you need to restart the IDE too? Can you run your IDE through an SSH session?

    4. I hate IDE with a serious passion. I pretty much had to learn Eclipse to do Android development, and it was miserable until I got the vi plugin installed and working, then it wasn’t all that bad. There are two big problems with IDE environments (I can see a whole ‘nuther holy war starting here). One is that they force some lame editor on you. The other is that they hide too much stuff. Now if you are a newbie starting from ground zero, you probably would like an IDE. But if you are skilled with say, vim maybe, you are going to be intensely frustrated wanting to let your mental muscle memory go to work editing for you.

    5. I’ve worked in data centers my entire career (25+ yrs), in administration in one capacity or another. Systems, routers, switches, storage, you name it. The key reason that I don’t fire up a GUI to do the bulk of my work is the sheer time that would be wasted doing so. When you consider that most of the work I do is remote, the time factor is compounded.

      There is also the issue that there are some things when dealing with things at the hardware level that you simply cannot do even when the vendor is kind enough to provide a slick web front end or dedicated GUI client. This is especially true when it comes to networking or storage. Does this translate into a steeper learning curve? Sure it does. This, however, should not bother the professional IT person.

      Give me SSH and shell access, (and VI, where applicable) and I can easily move between all the things I need to look at in a typical day.

    6. Why bother? GUI isn’t gonna help you on a headless barebone system under SSH. vi always works – and was one of the first Unix editors I learned on. If I need the power of EMACS I will edit usingTextWrangler or Notepad++. Whatever you get used to.

      Thanks for the article I learned some new tidbits.

    7. Because those “new editors”

      1 – Are slow compared to Vim (open a 1GB .json file in Atom if you can)

      “Who cares about bloated software”

      Well I guess most people who use their computer enough time to notice the software is bloated will get annoyed.

      2 – Not available on remote server on inside docker containers.

      3 – Using an editor written in JavaScript/CofeeScript + web technologies seems wrong

      4 – I don’t care who learns Vim or Emacs, I’m doing it for myself.

    8. Even with modern IDEs, I start by installing a VI editing mode, visual studio, eclipse, intelliJ even notepad++ are all in vi mode on my computer… and my colleagues swear because they can’t use my desktop.

  7. I much prefer vi / vim. I’ve been using some variation of it for 20+ years now. My fingers just instinctively do “vi stuff” and I find myself having to undo / redo stuff all the time when I forget that I’m using some other editor ;-)

    1. Don’t worry, it’s still the same old timers fighting the same war. They will soon die off and the war will come to an end as these old editors aren’t getting many new users in modern times.

      1. LOL. Not likely, given that VI and EMACS have been around for about 40 already. As long as bulk of the internet still runs on an OS that who’s name ends with an “X”, people that get things done will be using some variant of these editors.

      2. I’m 22y/o and love all this OG stuff

        I think people are getting too impatient these day, they just want to fire an IDE and everything to work off the bat. The issue is that shit’s always fleeting. In 20 years will Keil/VS/IntelliJ still be around?? Or will I have to run a VM just to work on some legacy code??

        Since the source for VIM & Emacs is out, it will always be around. It will never die, and even if it does I’ll just build a copy w/ gcc at the time

        1. If you need to edit config files, it’s enough. If you want to write programs, use proper IDE. Unless you are one of those old people that still use teletypes or punch card machines…

  8. I use neither, I’m good with notepad++ or textpad, both with syntax highlighting and regex. I don’t need much more than that. If more intelligent processing is required I use C# for binary or php for text or put it in mysql and use queries. But then I’m not really into embedded linux either. I like bare metal micro controllers or the full blown bloated windows os to do stuff but not much in between. Just my 2 cents worth.

  9. VIM is great especially when you need a flexible and powerful editor to work within cli/bash environment. Especially when you want to remotely write code on your headless RPi Zero over SSH.

    Emacs is good for that as well.

    The new kid on the block is atom. It is really powerful and flexible….but because it is an electron app, it can be quite the memory hog

  10. A tip that makes vi/vim a lot easier for touch typists is that on most systems escape is Ctrl-[ You can type this with very little hand movement, although I appreciate that remapping caps-lock is another common solution.

    I spend too much of my life working on old and esoteric *nix systems. Emacs *might* be there, vi is always there.

  11. About forty years ago I spent a whole day trying to learn TECO on a PDP-10. I thought it was the stupidest waste of time of my entire young life to that point. Both vi and EMACS persist with the philosophy that they are so great, you should devote a big chunk of your brain to memorizing their nonsensical key commands. Since then I’ve used vi for over thirty years and spent about 6 months using EMACS, while steadfastly refusing to “learn” either one. I know just enough vi to get by if I’m in a situation where a GUI editor isn’t available, and that’s the way it’s going to stay. EMACS? Simply doesn’t exist in my world.

    Oh: and Elliot, it was kind of lame, seeing that Al got a kazillion comments on his article and going to the same well. I now think of both of you as “Aliot Williams”. You’re both better than this.

    1. Re: Aliot Williams.

      We were brainstorming how we could good cop / bad cop a whole bunch of Hackaday-relevant topics. Microcontroller vs FPGA, amateur hacker vs engineer. He wrote an article ages ago on why one shouldn’t bother DIYing PCBs anymore. I do 8-mil, double-sided with one hand behind my back. Somehow we’re polar opposites, sharing the same last name.

      You don’t think that it’s healthy that we have many perspectives represented in our writing staff?

      1. Oh, I don’t have a problem with widely diverse points of view. It’s the “let’s see how big a war I can start”, followed by the “oh yeah? Let’s see how big a war _I_ can start!” sort of clickbait that twists my panties.

  12. i usually do stuff in vi(m). then i decide to do something ‘big’ so i start up a nice GUI text editor with all the bells and whistles, like bbedit or textwrangler. then open a shell where i test my stuff. after a couple of code+testrun cycles i usually realise that i am in the same ‘testing’ terminal using vi(m) to edit the code, then suspend the editor a do another test run.
    or just see myself stomping on ESC as i want to move the cursor backwards at the shell prompt.
    my background processes are tuned for vi. and it just was like 25 years or so.

      1. Ctags. Automatically including every function name into the ctrl-n autocomplete library. Diving up and down call-chains in the source code. So tasty.

        I don’t even _use_ tabs! That’s on my eventual learn-to-do list. (After five years of constant use…)

  13. 30 years ago I was porting EMACS to Xenix. The editor I used? vi. :)
    The editor I still know by heart? vi.
    The editor I’ve forgotten more about? vi.

    Simply put, I can find vi on almost every system. The ones I can’t find it on have ed.

    Can’t live without keys:
    J – Join current and next line
    A – Append to end of line
    a – append starting at cursor
    0 – go to beginning of line
    yy/pp yank and put the line the cursor is on.
    ZZ – :wq but one character less. :)

  14. I am no pro in Emacs, but all keystroke sequences in Vim golf’s answers look worringly large. I can do the first three tasks in GNU Emacs in far less keystrokes (counting Mod keys).

    1. oh please do.
      just choose *any* three challenges and put them together with the according emacs strokes in a reply.
      I don’t use EMACS so I would like to know how efficient emacs can be.

  15. Great article!
    Permit me to say that you’ve neglected on of the most amazingly useful vi commands that ever existed:
    ‘Pipe text object through command and replace’.
    For example, take the current paragraph (ie. to the next blank line) and run it through an external command and put the results back.
    eg. To sort a paragraph: !}sort
    To fill words to a line (if you have a ‘fill’ command): !}fill

    Write your own shellscript that reads stdin and writes stdout and you can use it in vi.

  16. How do folks with an aversion to vi search for text in man pages or anything piped into a tool that requires positioning (like less)? I’ve met super-smart, vi-averse neckbeards (n=2) who didn’t know that you could search a man page for text (ex. /verbose). Vi keybindings seem to be the de facto standard for *nix tools, so why isn’t that reason enough to be proficient in them?

    1. I just figured that regular vi users found that out by accident.
      (so used to thinking they are looking at vi that the / becomes an instinct)

      Similarly, once I became proficient in Photoshop, my mind began to look for CTRL-Z in real life situations!

  17. Text is what I expect to handle in a text editor, pure raw unformated text, perhaps minor config files too but it is unlikely.
    If I want syntax highlighting I search for another editor with that capability, if I wan’t layout capabilities, spell checking or anything else I’ll do the same.
    But what is appalling to me is that someone not necessarily the author of this or previous article can argue that monolithic software is bad and SystemV should not be used to then go over to that you “have” to use a certain text editor because it has all you could want from a text editor.
    Really? At least one would hope they could be consistent in their argumentation.

  18. Kids, I figured out in 1985 the simple truth: vi is for touch typists.

    If you want to edit text, and never have your hands leave the keyboard, you use vi. And you love it.
    If you hunt-and-peck then you will never understand the power of vi, and you will choose some other editor.
    If your mouse never leaves your hand, then vi is going to drive you crazy.

    I have been a touch typist since 1984. You know that I love vi.

    Different Strokes.

  19. Jeez, this HaD post is “CLICK-BAIT”!!!!

    There are multiple editors to choose from – some are simple, and some can be very complex. Each editor has a place and use in your (limited so-far) Life-Span. Be SMART and avoid this kind of nonsense Editor-X vs. Editor-Y “Debate”…

    1. “There are multiple editors to choose from” and most all of them are approximately the same — type stuff and use arbitrary key combos or pull-down menus to modify the text — except one.

      Vi(m) isn’t “best” and it’s definitely hardest to learn. But it’s also most efficient, especially for repetitive tasks. Such features might interest you. Perhaps not. Off you go.

  20. One thing I wonder is what the best approach for Vim with non US QWERTY keyboards could be ?
    I always struggle with standard keys that need modifiers on my keyboard (French – AZERTY), i.e. CTRL-] which would need to grab an additional AltGR to get the ] …

    So, is remapping everything the way to go or is there a clever way ?

  21. When I worked for swedish company I met one another “strange”editor in concepts near to vi – it’s name was VEDIT. It worked in DOS environment and had many things like macros, registers etc. presented in Vim today.
    Now I’m surprised, because VEDIT still exists and it’s price is $89!!
    Anyway I have used Vim for 20 years and it still surprise me from time to time. From last exploration if you know python, try to use it inside Vim also :-)

  22. Nice post.
    My only hesitation about using Vim is when I want to write prose. The Vim’s word wraping (at some fixed length, i.e. 80 characters) is pretty anoying. Vim does word wraping at screen boundary, not at pre-fixed length. How do you do when you write books?

    1. Trun off word wrapping entirely, and just write. It’ll wrap at the edge of the screen, but you don’t actually care where that is at all if you’re writing in some markup-style language. It’s all going to get re-wrapped by whatever text processor you use anyway.

      This means that every paragraph is a “line” to Vim, so you’ll need to navigate around by sentences rather than by lines to move around within a paragraph, but that’s the only real change from writing code.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.