Hacker News new | comments | show | ask | jobs | submit login
Your problem with Vim is that you don't grok vi (stackoverflow.com)
417 points by ez77 on Aug 22, 2011 | hide | past | web | favorite | 182 comments

One thing I think a lot of the naysayers here are missing is that you don't sit down and read a book on vim -- or even this stackoverflow answer -- and immediately expect to begin using all you've learned. It takes time. And it's painful at first. But it's a lot like gripping a tennis racket correctly or properly positioning your fingers at a piano. Your default method is indubitably the most comfortable -- by definition -- but the payoff of attempting the more difficult path can be likened to the magic of compound interest.

Every week or two, I teach myself one - ONE - new Vim technique/keybind/trick. Right now, I'm teaching myself { and } for jumping paragraphs.

In a couple of weeks, that will become muscle memory. Then I pick something new.

I know probably less than 0.1% of Vim, and I still find it better than any other editor I've used. One day I hope to reach 1%.

Except disregarding over three decades of human-computer-interaction progress is not the "proper" way of editing text.

But I already know how to use Emacs and have been using it for years. I can navigate around vim but there's little advantage to me for using it when I can do almost any fathomable task in Emacs up to and including use viper-mode (vim emulator that works really well).

Flame suit on, but I really don't understand the appeal.

I have reams of arcane bits of information to commit to memory already. .Net in two languages plus VB6 for legacy code. SQL in more dialects than I care to list, each with their own quirks and limitations. HTML and JavaScript. XML and various associated technologies like XPath. That's just professionally; once I go home I can add in photography and music straight off with others at different levels.

There's only so many things one can usefully commit to memory (edit - yes, I meant am prepared to dedicate the time to committing to memory); odd bits are just easier to look up. So why, exactly, should I voluntarily use a text editor whose interface was already far behind the state of the art when I started school?

:q!. I've had others try to persuade me of the joys and power of vi; I'm not even slightly convinced and that is the one command I'm committing to memory.

"There's only so many things one can usefully commit to memory"

That's similar to not learning English because the dictionary is too large to memorize.

As jvanenk says elsewhere in here, it's muscle memory, not memorization. You don't "remember" how to walk or use a pencil, you just think about the goal (move body over there, write sonnet) and muscle memory takes care of the details.

Most vimmers have had the experience of someone watching over their shoulder and they say "wait, how did you do that." And then you have to pause and think it through, because you yourself don't know anymore, it's just in you.

It would be ludicrous to try to learn all of vim, and it's absolutely unnecessary for using vim (or any other fine grained editor) effectively. You learn what's useful to you at the moment. If you do anything a lot that irritates you, there's almost certainly something in vim (or any other power editor) that will reduce it down to a keystroke or three.

I'm not saying you should learn and use vim, only that your objection (too much to learn) is misplaced.

> Most vimmers have had the experience of someone watching over their shoulder and they say "wait, how did you do that." And then you have to pause and think it through, because you yourself don't know anymore, it's just in you.

I had the interesting experience of learning vim over the course of many shared ssh+screen sessions with an experienced vim user, trying to get work done. "How'd you just do that" represents my primary method of learning for a while, and I definitely got a response of "hang on, let me try it again so I can tell you" more than once.

Most vimmers have had the experience of someone watching over their shoulder and they say "wait, how did you do that."

I agree wholeheartedly. Watching my colleague to code in vim is a turning event of my programming career.

Here's why I switched to vim full-time: Ubiquity across time and platforms.

If you invest the knowledge to learn Vim now, it will still be useful as long as keyboards exist and are used to write programs. You can also use it whether you are on Mac, Windows, Linux or whatever future OS comes out. You can use it over a high latency flaky SSH connection surprisingly effectively.

The notion of state-of-the-art is a red herring. Vim is a reasonably optimal mapping of all the keys on the keyboard to general purpose editing tasks with reasonably optimal internal grammar for combining commands in a logical way. In terms of general purpose editing, I don't think it's possible to make something "more advanced" than Vim, just different.

Of course in the GUI and IDE department there are many advancements, but how much are these worth? The answer is that if you pour millions of dollars into IDEs for constrained languages like Java you are going to get some specialized tools that outperform general tools like Vim or Emacs without similar language-specific optimization. That's great as long as you stay within the approved ecosystem, but not so good if you want to venture off into a new language or DSL that doesn't have IDE support. Personally that feels stunting to me; I want to try out new technologies at will without feeling unproductive until some monolithic software package decides to catch up.

Over the years through all the GUI advancements, the UNIX philosophy has proven that it still provides some of, if not the most fertile ground for creative hacking. I'd rather have 200 CLI utilities than 10,000 special purpose apps with thousands of non-orthogonal knobs and dials. Vim is a similar foundation for text editing. I can get some amazingly powerful plugins for specific uses (Fugitive makes "state of the art" git GUIs like Tower look like Playskool toys), but its bare functionality for manipulating text files is enough to get my comfortable and productive in any new language quickly, and I know I'll never have to learn a new editor for the rest of my life.

But why optimize for the lowest common denominator? I spend 95% of my time coding on the same laptop, in the same languages. I was a longtime emacs user but there's just no way I would write Java or Cocoa code without the support of an actual IDE now. The benefits of a tool that really understands the structure of my code instead of the surface syntax are just too substantial. If I have to use a generic editor for some new random syntax it's not that painful.

Besides, the basic cursor movement keys are standard across all text-editing widgets, at least on a Mac, and those are the most crucial to have in common. Using a "dumb" editor like Vim or Emacs seems like a premature optimization to me.

I found it easier to grasp vi's 'command mode' versus 'edit mode' when I realised that most other text edits use a modifying key (ctrl+, alt+) to indicate to the editor that you want to run a command rather than enter text.

Command mode in vi is kind've like a Caps Lock, but for commands. "lock" goes on (enter command mode) and you're running commands. "lock" goes off (enter edit mode) and you're entering text.

I realise it's not quite the right way to look at it, but it helped put a big piece of the puzzle in place.

I like your comments on the merits of IDEs vs. general utils. The overwhelming majority of people at my school use Visual Studio, they look at me funny when I use vim. I just say: "Linux is my IDE, vim is my text editor." Everything their IDEs can do, I can do with either vim alone or a combination of vim + shell/python utils. (Of course, sometimes this is too hard to do to be worthwhile, and the MS world enjoys a lot of proprietary products that have had years of maturity and don't have OSS counterparts, especially in the gaming industry; it's a seductive environment.)

I use auto-completion when I think it's worthwhile, my vim supports tab completion in python files. My current exception is using Adobe's Flash Builder for Flex development since I needed to make programs now when I started, and didn't have time to learn the language+standard libs (which has consequently meant that I still don't know those things as well as if I had avoided auto-completion). Fortunately Flash Builder is built on top of Eclipse, so the occasional time I need Eclipse's integrated debugger for million line Java projects it's not a foreign interface. Yet I've never bothered to truly get used to Visual Studio, or Dreamweaver, or Delphi. To me those seem like the extraneous pieces of information I don't need since they're useless outside their very specific domains whereas vim is an investment that pays off time and time again in all sorts of areas.

You may want to look into ViEmu to use vim keybindings in Visual Studio


  You can use it over a high latency flaky SSH connection
  surprisingly effectively.
As a GUI editor user and generally vi(m) ignorant person I have a question about that. Flaky connections - that's where I live. Right now my typical MO is to open an SFTP connection to a remote dev server and edit the files on it by using an SFTP-capable editor. Essentially, the editor pulls the file, displays it for modification, and commits it back to the server when I press CMD-S. This works so incredibly well because the editing phase itself has no latency and saving 2-3 kB of (compressed) source doesn't take longer than a few seconds over the worst of connections.

Now, does vi(m) have a similar feature or did you mean (as I expect you did) that editing over a terminal connection to a vi instance that runs on the actual server was surprisingly effective? Because if you did mean that, you haven't seen actual bad connections yet ;-)

Don't get me wrong, I always have a Terminal window open, I love the command line. But I wouldn't use it for remote text editing unless it was an emergency. Also, I kinda like syntax highlighting in my editor.

My preference is to work as you suggest: edit locally, transmit the saved version remotely. vim even supports this with its ssh filespec, though I'll generally work, edit, and either rsync or git push these days.

Sometimes, though, remote editing is where it's at for whatever reason, and vi/vim is still probably the least sucky tool for such an instance.

Even if it means doing copy/paste into the remote session:

:r ! cat <paste> EOF

... works surprisingly well too.

By using sshfs (doesn't require any extra setup on the server side) you don't have to use an SFTP-capable editor.

I edit files across a satellite connection on oceanographic vessels a few thousand miles away at sea (often 1000ms+ pings) and sshfs is wonderful

and as the other poster points out, syntax highlighting working fully requires correct terminal settings

  By using sshfs (doesn't require any extra setup on the server 
  side) you don't have to use an SFTP-capable editor.
I know, but that isn't really the point at all. Whether I need to start one program or two in order to make the connection isn't the issue (but I sure prefer it in one package). My post is about avoiding latency when working online with a retrieve-edit-store workflow as opposed to transmitting every single keystroke and screen update over the wire.

And yes, as you already observed, I stand corrected on the point of syntax highlighting.

It is a nice idea and as a Plan 9 user I can attest to its power.

However The Fallacies of Distributed Computing [1] are not just whimsy.

[1] http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...

Actually, VIm has built-in support for editing remote files over ftp, rcp, sep or http:


It's not perfect, but I prefer it to using vim inside a remote shell and waiting for cursor to move to the right point after I press a few j's.

vim has syntax highlighting.

Not on a command line SSH connection, does it?


Whether or not this extends to color depends on the terminal / termcap support at the remote end, but at the very least bolding and reverse-video should be supported.

In most instances, you'll have full color syntax highlighting, though I've found I've got to down-rate my terminal. e.g.: rxvt-unicode isn't known on all systems, but rxvt, ansi, linux, or xterm generally are, and dropping past "rxvt" on that list is very, very rare.

You do realize that you can compile a termcap an set it up in ~/.terminfo, right? E.g.:

  % tree ~/.terminfo 
  `-- r
      |-- rxvt-unicode
      `-- rxvt-unicode-256color

Hmm, I never noticed that during my casual visits to vi-land. I'll definitely look into that, it's probably time to read up on how to massage vi's settings...

If you want syntax highlighting you should be using Vim, not Vi. On many (but not all!) modern systems 'vi' will invoke Vim in compat mode forcing you to manually reenable Vim's additional features. Some modern systems come with a Vi provided by elvis or even busybox, always check what you're actually using.

Alright, I promise I will check it out. I admit I do feel a bit behind the curve for being a programmer for so long while never really having looked into vi in depth.

>You can also use it whether you are on Mac, Windows, Linux or whatever future OS comes out.

I can use modern WYSIWYG text editor on any unfamiliar platform anyway, my aptitude with computer GUIs is sufficient enough for that. Notepad++, Textwrangler, MS Word, whatever... they're not exactly difficult to pick up.

Yes, but then you're stuck with thte least common denominator.

Ubiquity across keyboards also. You can easily forget where home/page up/page down/delete/backspace keys are, even its existence (as macbook don't have some of them), some keyboards also use them fn combo.My last laptop's left key didn't worked for month and I did not feel its need.

Abstracting away from the traditional arguments regarding modality and keybindings, emacs serves the same purpose.

I selected emacs in large part because I was tired of learning different editors, one for each platform.

> a text editor whose interface was already far behind the state of the art when I started school?

And what exactly is this state of the art you talk about? If it's the IDEs you are talking about, saying that they suck at text editing will be an understatement. Code completion, refactoring support etc isn't text editing.

When I am using a language which requires a lot of boilerplate and demands an IDE, I go for some plugin which gives me vim keybindings(eclim for java, don't do much C#).

Code is text at the end of the day, and something which isn't good at munging text isn't going to be my code editor. Eclipse, Visual Studio are both good tools, but they aren't good at munging text, not at all. And the boilerplate code they generate doesn't do anything to mitigate this.

> So why, exactly, should I voluntarily use a text editor

Because it isn't a pain in the ass like the IDEs when it comes to text editing.

> And what exactly is this state of the art you talk about?

Oh, that's easy: Emacs :-)

Yes, but vim doesn't do code completion or have refactoring support, which is something I like in my IDE.

Before someone tells me it does, I've had competent vim users try to get C++ support set up for me before, and it is almost worse than useless in code completion, code refactoring, and even trivial things like "jump to compiler error/warning".

Both of these tasks are highly language specific. I guess your IDE can do it for your language but can it do it for Python/Haskell/Lisp/whatever?

In Vim, these features tend to be plugins. Vim ships with some of these plugins by default (e.g. C and C++). Autocompletion with C and C++ works using cscope and ctags, which also are very powerful code navigation tools. There are plenty of other tools available.

Vim has excellent "jump to compiler error/warning" support called the quickfix list. Just invoke your compiler using :make (you can configure what it does, by default it runs make) and look at the errors in :copen, browse with :cnext/prev.

All your arguments against Vim were false. Please don't spread such BS that can scare new people away from Vim.

I feel that at least telling them they are in for a hard slog, is a good idea. I've wasted at least a couple of months, using vim as my standard editor, before giving up and going to something else.

Vim's "jump to compiler error" tends to get confused by C++, and gets very confused by clang (this is from experience). There are indeed a huge number of tools available, for code navigation, for C and C++ in vim. Each of them has it's own faults and none of them have anywhere near the functionality of eclipse (although last time I tried vim, clang_complete didn't exist, and might now outperform tools from last time I tried).

vim does do code completion ...

For example, in my gvim, control-p shows the autocomplete list.

Does it work with the boost headers? Or member functions? Eclipse and VS can handle these both with ease.

If you think it does, I'd be interested to know your setup, as I've never been able to get such a thing to work effectively in vim.

    -   Complete namespaces, classes, structs and union members. 
    -   Complete inherited members for classes and structs (single and multiple inheritance). 
    -   Complete attribute members eg: myObject->_child->_child etc... 
    -   Complete type returned by a function eg: myObject->get()->_child. 
    -   Complete the "this" pointer. 
    -   Complete a typedef. 
    -   Complete the current scope (global and class scope). 
    -   Complete an object after a cast (C and C++ cast). 
    -   Complete anonymous types (eg: struct {int a; int b;}g_Var; g_Var.???). It also works for a typedef of an anonymous type.

(disclaimer: I don't use it, I turn off completion everywhere I go.)

Clang_Complete is another completion plugin, though it is not compatible with OmniCppComplete.


Thanks for the suggestion, but it uses ctags, which simply chokes on boost.

I use clang_complete on Mac OS X and it is a dream. It works without issues on the Boost libraries and overall is very fast and efficient.

Try uxp's suggestion then, which doesn't use ctags.

I'd say it's an old interface, but that it's still state of the art (there's a reason there's a vi/vim mode or plugin for every major editor except emacs and that you've seen a resurgence of modal editors as the programming world has moved away from boilerplate laden languages). Don't think of it as knowledge competing for headspace for languages and quirks but as knowledge that augments those arcane bits.

For your :q! example, it looks daunting but you really don't end up memorizing it verbatim like that, much like you don't memorize adding semicolons verbatim to the end of your C# lines of code or adding closing tags to markup languages, it's just part of the language, a line end implicitly requires a semicolon so you just do it, vim commands are prefixed with colons so you just do that too.

The q is quit, which is hardly any worse than remembering Cmd-q or Ctrl-q is quitting for OS level shortcuts and the exclamation mark means "force", so it's usually unnecessary unless you're trying to quit without saving your changes, or doing something the command otherwise wouldn't normally allow. The exclamation mark is used in tandem with other commands too, so you don't mentally remember ":q! is how I quit a file without saving changes", you memorize how to build up the command you want, "I want to issue a command, type a colon" then "I want to quit the editor, type a q", then "I want to quit without saving, so force it, type an exclamation mark". And if it really bothers you, you can configure vim to prompt you for an action if it would normally require a ! and you left it off.

> (there's a reason there's a vi/vim mode or plugin for every major editor except emacs

Viper? Vim mode?

That's another story that these vim modes in emacs are hated by both emacs and vim users. I don't know who exactly they cater to.

I agree that they're usually sub-par, but it's telling that someone on every major IDE tries to address the lack of modal editing. Personally, when I'm using .Net or Java, I tend to keep the IDE open and open up gVim along side it, since it's rare for me to need the text-munging capabilities of vim simultaneously with the boilerplate/intellisense features of the IDEs.

I'm someone they cater too. I'm somewhere on the intermediate end of the scale for vim users and I love it's modal editing. But I also like modifying and specializing my editor and VimScript is to put it mildly a really sucky scripting language. And no the {perl,python,ruby} bindings do not improve the situation significantly.

Viper with Vimpulse get me close enough and still allow me to modify my editor in a lisp dialect. I'm willing to sacrifice some of the edge case uses of Vim to have this power.

It's not ideal but it's currently better than vanilla Vim or Emacs. I have hopes for Yi in the future but it's not there yet and development has only recently started to pick up on the project again so it has a ways to go.

VIM is muscle memory to me. I don't usually think about what I'm typing. I just think: 'I want this text over here' or 'I need all these phrases replaced with this new one' and then my fingers do it...like scratching an itch.

That being said, one still needs to learn it to begin with. I'm lucky that I decided to sit down during college and at least learn the basics. I'm not convinced that it makes sense for every one to learn VIM or Emacs if they are perfectly proficient as they are now. For me, it's the right answer as long as I'm not pairing with some one who doesn't know VIM.

I've found that using vi is like driving a manual transmission car after driving an automatic for a long time. There's a brief adjustment period but then it all comes back to me in terms of knowing how to use it.

I tend to be lazy and use keyboard shortcuts as much as possible regardless of the OS I'm using. With vi it's basically heaven since they were able to make it a powerful text editor without a modern GUI.

The cool thing about a good text editor is that you can use it for ALL of those things.

I'm an emacs guy not a vim guy but this fundamental point is similar. Being good at vi means you're good at editing arbitrary text whether it's VB6, SQL, HTML, JavaScript, XML, wiki markup, the output of 'find' or 'ls -l', or some randomly formatted table that someone sent you in an email.

Here's the appeal:

I first learned vi in 1986.

It sucked for about 2 weeks.

Then I got it.

For the subsequent quarter century, I've used iterations of the same tool, as my principle editor since the mid-1990s.

Since then I've used: WP4x+, WordStar, DOS EDIT, EDLIN, TSO/ISPF editor, MacWrite, MS Word in multiple incarnations, AmiPro, EVE and EDT on Vaxen, and a slew of other proprietary editors (as well as Emacs, pico/nano, ae, Lyx, AbiWord, etc.).

vi/vim is a standard you'll find on any 'Nix box, from BSD to SysV4 to Linux to Mac. Ports exist on a great number of other platforms.

As with other 'Nix tools, a key advantage of being a free software program is that it tends not to up and get replaced. The fundamental philosophy of vi (a full-screen curses editor based on ed with its commandset) continues through the modern incarnation (though I've got to admit that going back to old-school, un-featured 'vi' instances sucks).

While the free versions are now generally available, I ended up learning and unlearning a lot of emacs when I switched to a shop that 1) didn't have it and 2) the boss wouldn't allow it to be installed (didn't know enough at the time to realize that was a prime hint to up and leave).

I've saved myself having to unlearn a great deal of stuff by sticking with vi/vim.

Now: if you've got an editor which works for you _and_ can offer the same promise of persistance, bully for you.

But at least now you understand the appeal.

I could have written this. I learned a little vi in the mid-80s and have pretty much used it ever since. No other editor has stuck with me that way and I've seen most of them - ISPF, WordStar and many derivatives, WordPerfect, etc. Except Emacs. I just never got into Emacs because every system that had Emacs also had vi.

I think I spent the first few years getting to the end of a line with shift-A and Esc, copying lines by trying 13dd u 14dd u 15dd P jjjjjj p, etc. (Side note: even as I was editing this text I kept hitting ESC and bbbbbb.) I'll likely never know all the things Vim can do, but it's already enough that it's my fallback editor when I need to do a lot of editing or text manipulation.

I've used vi editors for longer than I remember, I don't remember any of the things I type. They just happen. I'm 30 btw, vi and its arcane "behind the state of the art" interface are only behind if you don't understand the reasons behind the separation. Every single time I login to a ssh server over a slow ssh link, I am imminently thankful I can type and update a file faster than the screen can refresh my changes. One thing for which vi excels at.

Also, don't use :q!, just use ZZ, its quicker.

If you want to learn how to do something vimgolf is a good choice as the goal is to do a task in as few commands as possible.

Think of it as talking to your editor in as minimal a way as possible. http://vimgolf.com/

> Also, don't use :q!, just use ZZ, its quicker.

But ZZ is equivalent to :wq, which is different. If OP finds themself in a text file in vim by accident and started typing a word, they will likely NOT want to save those changes. (Hence OP's :q!, rather than :q.)

If you've made changes then yes its not equivalent, keep in mind I NEVER open a file for editing unless I intend to edit.

That is what view/more/less are for.

Oh, cool! I didn't know about view, actually... I'd been using vim to poke around in files because I'm familiar with the navigation key commands, and was always keen to make sure not to edit something. But opening as read-only is great!

Something that continually surprises me is how a lot of these things are interrelated historically, but people teaching these things either don't know that or don't think it's important to pass on. By which I mostly mean stuff coming through the unix tradition like grep, regex, vi-keys etc.

You meet these things for the first time and think, why would I bother learning all that arcane knowledge just to do this one thing, but then later you realise that you can leverage that knowledge across a wide range of tools. Obviously you mention C# and .Net so you swim in a different pond and are less likely to see the same level of reuse, but that doesn't mean it's not there.

I have been using vim for a little while now (1+ years, so I still consider myself a newbie) and I have found that it has become second nature, I don't think about it anymore I just do.

I learned how to drive a manual car a couple years ago and these days I just don't think about it anymore. I shift completely absentmindedly, it just happens. The response is built into my body, I no longer have to provide it any thought power.

I've become much more productive with vim than I have with any other text editor.

I am but an egg, but . . . - Knowledge of vi keystrokes allows integration of automated text editing with other shell commands, as those keystrokes are scriptable. - Search and replace commands allows fine-grained specification of global texts. Tricks like "delete all lines from the start of this code block to the end" are no big deal. - vi easily incorporates the output of shell commands into the text you're editing.

I really appreciate your comment. Anyway, this comment was not meant to convince non-vi-ers to start using vi. You don't start using vi because it has a great ":" command that you can use from line X to line Y to apply some other command to them and nobody actually expects you to (or should, at least). It was for people struggling while getting started in vi. People like me, on their way to true programming-buddhahood. Not everybody has that goal and not everybody should have. Kudos for following your path. (But also, I think that you don't need to read vi stuff because it will not give you anything, anyway)

re commit to memory. I put forth that a programer's editor is the most important thing to commit to memory. Also, with vim you commit to muscle memory.

Vim is "far behind he state of the art" same way Lisp is. That is it's so far beyond state of the art that it takes most editors/people years to realize what they have is just a weak / limited implementation of vim.

Given that, I STRONGLY believe people's brains work different. And what may be the most awesome editor for us is not the same for you.

Given that, you can not know if vim is for you without using it (daily for programming editing) for at least a year.

> There's only so many things one can usefully commit to memory

Can you refer to any scientific research to back up that statement? My impression is that the more you use your memory, the easier it is to remember new stuff. Memory seems to be more like a muscle, the more you use it the stronger it gets, rather than a bucket that can get filled up.

I voted you up since I agree with your muscle premise in real world situations with realistic amounts of information, but here you go: http://en.wikipedia.org/wiki/Bekenstein_bound ;)

I think it's sensible if thought of as more time investment rather than how much you can commit to memory. Learning something like vim is going to take some time and is perfectly reasonable to question if there is a whole other stack of things you are also attempting to become proficient in.

It is reasonable, but... I have been using vi/vim for almost 15 years now. Various technologies have come and gone (or persisted), but the underlying tool I use to make them sing has not. Early in my career I made the decision to learn vim, and it is not a decision I have ever regretted. Yes, it meant that in the beginning there were things that took me longer to do. But now? Now I can do so much more so much quicker.

And after a while -- and it is not all that long of a while -- it becomes second nature. The fundamentals become a part of your fingers, just like touch typing. You no longer have to hunt and peck to type out the word "lightning". You just do it. vim's keybindings become similarly engrained. It just takes practice.

This is a matter of cost vs benefit, not memory.

> I've often done things iteratively and interactively that could probably have been done more efficiently if I'd taken the time to think out the correct incantation.

Maybe not. Efficiency is a measure of the time it takes accomplish something. 'Puzzling out how' can sometimes be a more relevant bottleneck than 'number of keystrokes.'

The difference is, if you just do it mechanically, you'll never get faster at it - the limit is the speed at which you can hit keys in a coordinated manner, which is not going to improve much over time. Something that takes you 100 keystrokes and a mouse movement today will still take you that much in a year's time.

However, if, with a minute of thinking through the correct incantation, you can turn that into 10 keystrokes and no mouse movement, next time it will probably only take you 40 seconds to remember how to do it. Then, 30 seconds. Then, 20 second. Then, 10 seconds. Soon enough, if you do it often, it'll become automatic. And then you'll have locked in a more than 10x gain in productivity which would have been impossible the dumb way.

This is also the reason we spend years learning how to program instead of just copying and modifying bits by hand, by the way.

I find that in vi the fastest method for me is usually a mechanical combination of visual mode/movement/yank/paste rather than figuring out in my head where the next "word" ends or how many times to repeat the command. I've never been good at that but I consider myself very fast in vim. It is rare that I have to repeat a command and then I usually use the macro recorder and repeat it a random amount of times until I get it right.

> [Optimization is often beneficial.]

Your point is indisputable. Fortunately, it's not inconsistent with my own:

>> [Optimization is sometimes harmful.]

Optimization pays the greatest dividends to tasks which:

(1) could be brief,

(2) but are quite long and

(3) frequently necessary.

As to vim: On (1), brevity, Vim is powerfully so.

On (2), length, I don't recall any of my meta editing tasks involving "100 keystrokes and a mouse movement." Customizable shortcuts can trim down the outliers.

On (3), frequency, this surely depends on the person and task. I rarely delete every third occurrence of x between the seventh and ninth y... but if I used vim, I would make a point to.

So, I would turn to vim if there were several meta-editing tasks I routinely performed, each requiring a large number of keystrokes, each of which vim could reduce.

And hey, maybe this is the case. I'd love to see a plugin that analyzed my editing style and made suggestions to make me more efficient.

But originally I was just noting that efficiency and optimization are messy.

> On (2), length, I don't recall any of my meta editing tasks involving "100 keystrokes and a mouse movement." Customizable shortcuts can trim down the outliers.

As a simple example of that, using a dumb text editor like notepad as the baseline, changing the same 10 characters on 10 consecutive lines will take at least 200 keystrokes (100 DELs, 100 times typing the same characters back in, plus the movement keys - about 9 to move down to the next row.

With a bit of thought, in notepad, you can reduce this a bit. use Ctrl-C and Ctrl-V to reduce the amount of typing - but you'll still need to either DEL or select the words to replace, in the same location on each line.

With a more modern text editor, you can select a rectangular area and replace the text within it. In vi, replacing those 10 strings on 10 consecutive lines will take (starting at the first character to replace, like Notepad, and assuming it's a single word inside separators):

Ctrl-V e 1 0 j c A_NEW_WORD

That's 16 keystroke instead of over 200, with no mouse movements.

This is something I do frequently enough that I didn't need to even think for a millisecond to bring to mind the keystrokes needed to do it.

Now, I'm not arguing your editing style isn't different - maybe you've never needed to do this - but I would argue that this is a fairly common programming text editing task.

Why do you have the same 10 characters on 10 consecutive lines? Sounds like that is probably a violation of DRY, at least it always has been when I encountered something like that. Also, if you are comparing vi(m) to something, please don't compare it to notepad. Every editor and IDE I have used in the past few years has rectangular selection. Commonly with alt+click and drag, or shift+alt+arrow keys.

There are lots of scenarios when this comes up:

- braindead configuaration files. - data files that need some massaging - commenting out code blocks in languages which need a prefix comment delimiter on each line (e.g. python's # or haskell's --) - any time you are doing a series of operations calling functions in a module or from a single class/object and the name changes (e.g. foo.x();, foo.y(); foo.z(); and so on);

OK, I can potentially see where vi(m)'s rectangluar selection would be good for editing config files and such, but I'm pretty sure all modern editors have rectangular selection anyway (notepad is not a modern editor). My IDE has the ability to rename a variable and to comment/uncomment a selection which solves your last two problems.

I wasn't defending vim over your editor, just answering the question of when there are valid times to do 10 lines of block change. 2 more that came up for me yesterday:

We changed the data format being sent over JSON now I needed to:

1) make a bunch of int declarations into float declarations, fortunately those tend to bunch up.

2) Change a bunch of getInt calls to getFloat calls, but those are also bunched up together.

In a dumb Editor:

  1. Ctrl-shift-Right to select (1 or 3)
  2. Ctrl-C copy (1 or 2)
  3. Ctrl-H Open replace dialog box (1 or 2)
  4. Ctrl-V Paste the old (1 or 2)
  5. Tab (1)
  6. A_NEW_WORD (10)
  7. Enter (1)
  8. Replace (1) x10 (or Tab + replaceAll == 2)
  9. Escape (1)
  Total 27 or 32
  That >80% Better.
On an intelligent IDE:

  1. Right Click Key (1)
  2. R - to choose refactor (1)
  3. R - Rename (1)
  4. A_NEW_WORD (10)
  5. Enter (1)
  Total: 14
I still want to learn Vim, because I somehow find it 'artistic'. There is some inherent beauty in Vi that I would love to be a part of. Unfortunately, the learning curve is fairly steep and the fear of losing productivity for 2 weeks is too huge. I still use vi for small changes, but for coding I find eclipse a more useful tool.

There's another giant advantage to renaming in an IDE over a text editor: You can be sure not to clobber any other variable/method references.

Here's an example, I want to change the name of my MyClass.Execute() method to something more descriptive. In an IDE, I right click and rename and I'm done.

In vim or other plaintext editors this is practically impossible without manually inspecting each call-site. Is "foo.Execute()" a reference to MyClass.Execute() or YourOtherClass.Execute()? Without actually parsing the program it's tough to know.

I love using vim, and I'm getting better at it the more I use it, but this is one of the major productivity drains I encounter that an IDE does way better.

You forgot to take the conversion rate between clicks and keystrokes into account.

  c = (k.d.t.r) / 13333337

    c = click
    k = keystroke
    d = distance in centimeters between the "J" key and mouse
    t = area to be clicked in pixels²
    r = screen resolution in pixels²

There are no clicks, the Right Click Key on keyboard is just too awesome! :)

> Ctrl-V e 1 0 j c A_NEW_WORD

Another approach is something like:

But alas, that's 21 keystrokes.

(I post this now because it was closer to my first thought on how to approach the problem, and wanted to write it out to see if it was shorter. It wasn't, but maybe it'll be useful to someone. I learned about <ctrl-r>/ (fills in a search and replace with the previously searched expression), while writing it.

While I agree with your initial arguments, that last sentence doesn't make a whole lot of sense.

Learning to program takes almost as long as learning to use vi (hah!). Many people learn to program to automate a simple, boring task. Many people learn to program better by automating more of those tasks, before they progress onto "full programs" that have more of a stand-alone nature.

Within those full programs, there are many times when we continue to have a choice between doing it the quick but dumb way, or taking a little more time and doing it the clever and reusable way.

Of course, sometimes this can be taken too far - see yak shaving - but there are many points, while learning to program and while programming, where we face the choice between "do it manually in half an hour" and "take two hours to program something that will do it in 3 seconds". The difference between a programmer and a non-programmer is, largely, that given this type of choice, the programmer will tend to pick the latter option.

It is always a long term goal to puzzle out a better way to solve the same problem. Doing that often will lead to better solutions over time. Not doing that will keep you on the same level you are now (or might even help in decreasing your skills). In a short term any solution is fine, of course.

I just started using emacs as my primary editor for work, and I face this all the time. I'm completely sure that most of the things I do can be done more efficiently and with fewer keystrokes. But to stop and think about it breaks my flow, and stops me from thinking about the code itself.

The trick is to just spend a few minutes each day reading up on a command or working on your config. There's no rush because emacs will be around for the long haul.

It's not about the most efficient command sequence at every moment in time, rather it's about building up the mastery that allows your natural instincts to subconsciously pick more efficient paths.

My problem with Vim is that it can't be configured to validate and correctly complete code in realtime (except by mad-science brain grafts like eclim). Note that ctags style word completion is like 1% of enough. The important thing is that code is either visibly wrong (red squigglies) or visibly syntactically valid (no red squigglies). That massively cuts down the contribution of trivial typos to bug hunting. And to do it requires a full parse and analysis of the language being edited, going on in the background as you type.

Without that, Vim is reduced to a quick hacks editor, or an editor for languages where no realtime parse is possible.

Maybe I just don't fat-finger as much as the typical programmer...but intelligent code completion and typo detection are really not things I value in an editor. <C-N> buffer-based completion is more than sufficient when I need to save some typing.

The point of code completion is not just to save typing (although that is desirable benefit), code completion helps you browse around a new library that you're unfamiliar with and read the documentation right in the IDE. I don't know how I would have gotten through the Swing/SWT based assignments in school without have the documentation right there in IDE.

It also depends upon the language you are using. I don't know if you're using Java or not but one can use all the help possible in catching typos while working in Java just due to the verbosity of the language. Programming in Java without an IDE is like working on rails apps without using any of the scripts and generators, it's doable you just have to write all the boring boilerplate code manually.

As with anything, after you start practicing you stop making beginner mistakes. If you switch to Emacs or Vim today, you are going to typo things that Eclipse would have auto-corrected for you. That's because you've never practiced typing correct code from memory. But use Emacs or Vim exclusively for a month, and you'll see that you are much better at programming than Eclipse is. You'll write code more quickly with fewer errors.

Also, using autocomplete to explore APIs is one of the worst programming practices I can think of. The docstring for one method is not nearly enough information to tell you why you should call the particular method of the particular class that autocomplete suggested. In order to be sure you've made a good API use decision, you need to read the documentation and code for the library, and then decide to use it. Anything else is a hackish shortcut that will surely waste more of your time than it saved.

And, if you can't remember the names of methods you know you want to use, maybe it's time to refactor. Or practice remembering. If you want to be bad at programming, Eclipse will make your life slightly easier. If you want to be good at programming, start programming and stop commanding an autocomplete tool.

Code completion, syntax validation, and built-in API documentation are useful features. To say they're things that only beginners or bad programmers use is absurd. I have much better things to do with my time than memorize the exact name and parameter order of every method in an API.

I primarily use Vim as my IDE, so I'm not saying I prefer Eclipse or other IDEs. But I don't pretend that Vim is perfect and using an IDE is a sign of inability.

This used to be something I greatly valued in IDEA and VS when writing Java and C# respectively.

Now, I much more highly value consistency. In any given day, I may edit one of a dozen languages or hundreds of config file formats.

I've found that using code correction and autocomplete serves rather to break up the flow of putting code down. It's not important that I wrote "mlloc" instead of "malloc", the compiler will catch that later and I can fix it then. The important thing is that I remember how big I wanted to make the memory region, and then what algorithm I was going to apply in the Big Important Loop coming up.

And if you need code completion, your names are too long ;)

I can appreciate continuancy of mind, but red squiggles shouldn't be a deterrant to that. Rather, it is simply saving you the step of compiling before giving you information. You can just as easily train yourself to not worry about red squiggles until you're finished with the task at hand.

As for variable naming, the better question is:

Why would you willingly choose less descriptive variable names when there are editors that will help you produce more readable code?

editors that will help you produce more readable code? The problem is your editor helps you produce more code, readable or not. The goal is to produce a good program, not more code.

I use clang complete for vim. For me it is more precise than Visual Studio 2010 Intellisense (they use edg for code completion).

http://symbolsystem.com/pyflakes-vim/ ?

There are similar plugins for other languages.

Halfway there is syntastic...

maybe it's because I started coding in the 80's but I've been doing this "autocomplete" and "full syntactical parsing in the background as you type" thing in my brain. Along with my ability to refactor "bareback" it may be why I prefer tools like vim over IDE's.

Not all of us have the comfort of permanently working in a programming language we're familiar with. For languages I know pretty well, like C++, I only use vim. But for languages I hardly ever use and only if I have to, a "real" IDE can greatly improve my speed of development.

What language is so different from the ones that your familiar with that you need tools? Autocomplete doesn't help you learn a language, it just auto-types the names of methods that happen to be available in a certain class. It doesn't tell you that you've selected the right class or right method on that class, though. That requires understanding of the code you're writing and the code you're using. And at that point, you might as well be using vim.

Typing is easy. Programming is hard. Optimize for programming.

This is one of the reasons I wish all standard text controls came with an optional VI mode.

This is one of the reasons I'm happy to be Emacs and OS X user at the same time. Most of system input fields support main Emacs' shortcuts.

It's All Text! achieves pretty much that by letting you write any text in your editor of choice (which can be gvim).

Similar extensions exist for Chrome, but they require running a server in the background since Chrome doesn't let them execute external processes.

And one step further is to have vi-like binding for navigating the web, switching tabs etc.

Vimperator and its recent fork Pentadactyl do this for Firefox, there's similar (though when I looked into it, less advanced) add-ons for Chrome/ium too, I think the one I tried was called Vimium.

I was worried using such an invasive add-on would trip me up with Firefox's new rapid release schedule, particularly as I jumped to Pentadactyl because it supported version 4 first/better) but I'm up to Firefox 6 with no problems as yet.

My first browser was Netscape Navigator and today but obvious I'm on firefox. The only reason I am still stuck and not moved to chrome/ium is due to Vimperator. Your comment was a validation to me :) . I have nightmares that with chrome/ium becoming so popular, I might lose Vimperator.....

Thanks. I think it'd still be useful though to shift from the paradigm of everything goes in my text editor to the paradigm that my text editor is already in everything.

If you're on OSX, you can use Keymando(http://keymando.com) to get vi-mode inputs. Check out Steve Losh's vi-mode plugin at https://github.com/keymando

Interestingly emacs seems to be popular in Japan (where I'm based) but I always preferred Vim. Though it is rather complex.

Interestingly if you want to do any Japanese text editing, most IDE's or editors fail horribly. I almost always find myself falling back to Vim.

Mind you, I really like textmate. Sadly, it sucks at Japanese. And will for the time being.

I just have to say thank you so much for this comment!

I do a lot of Japanese text editing and I've also been learning Vim recently, but I had no idea that Vim recognizes Japanese words. Many times I've thought, "It's too bad I can't (effectively) use Vim for Japanese also," but I was just assuming it wouldn't be able to parse the words without spaces.

I just tried it and my mind was blown when w moved forward in completely logical increments without plugins or anything. I still can't believe something like Vim would include a native Japanese parser, but now I think it's time to rethink my workflow...

EDIT: I just tested some more and realized there isn't actually a semantic parser, but it's just treating any grouping of one syllabary (kanji, hiragana, katakana) as a word. Except for some debatable weirdness around conjugated verbs, it actually feels fairly natural given the rhythm of the different characters used in Japanese.

It's funny how there are regional differences in this. I'm from Finland and for some reason Emacs is very popular here too. But I guess it comes from the fact that some default keybindings in Vim are horrible to type with a Finnish keyboard layout. On the other hand, it doesn't take a whole lot of customization to get comfortable with Vim.

I switched from TextMate to Vim last year because I realized that I don't want my editing eggs in a closed-source basket.

It's great to see all the vimmers on this thread. One question, WHERE are all you guys? I work at a very large corp. and I am hard pressed to find another vimmer when it comes to discussing the beauty/elegance/purity of vi at the water cooler. May be we need a secret handshake or nod?

From my experience, at Very Large Corp, if there are any vim users, they're likely in ops rather than developers. In smaller companies, you're much more likely to run into vim users. My company of ~10 developers has 6 devs that are significant vim users.

I think the recent DevOps movement (which is actually a label to something that's been around for a while), is strongly correlated with vim (or emacs) users as well. Developers who get their hands dirty on remote systems often want a tool as ubiquitous as vim.

I wonder if the set of folks discussing here is completely different from the set of folks that saw Notch (Minecraft creator) coding on the weekend. Everyone seemed to agree he was very productive developing his game inside Eclipse.

Eclipse is not fundamentally less productive than vim; it's just productive along a different axis. Eclipse can sling around Java syntax like no other, but it's no better than notepad at editing text. On the other hand, vim has a very cursory understanding of Java syntax (as in, it knows that "for" is a keyword and "{" starts an indented block; i.e., just what is necessary for syntax highlighting and indenting). As a result, eclipse is really good at moving around your source, which is important when editing large software.

Vim, on the other hand, is more of a tactical editor; it lets you compose a small set of primitives into a incantation that will rearrange arguments in a function call, and then compose that with the repetition primitives to do basic refactoring. The effect is the same, but the way you go about it is very different.

And hopefully you train to make those in a way that no syntax errors are generated...

I wonder how much kvetching could have been avoided simply by making Vim open up in insert mode.

The only time I might want vi in insert mode at startup is when I'm creating a new document. Every subsequent time I open the document I'll need to first navigate to somewhere else in the file before I begin typing. They made the right decision.

You can get this behavior if you launch Vim as `evim` or by setting the 'insertmode' option in your .vimrc. It's important to understand, though, that there are very good reasons why this is not the default.

This might be reasonable for the sort of user who only starts up Vim on rare occasions, say when editing a remote file via SSH, and doesn't care to grok the modal style. It would certainly reduce (though not eliminate) confusion for people who encounter Vim for the first time with no prior knowledge, see a strange screen with tildes running down the left side, and spend 20 minutes trying to figure out how to quit, only to give up and just kill the process manually. But crucially, it defeats the _entire purpose_ of using Vim for the non-casual user. `i` is the command that turns Vim into little more than MS Notepad with syntax highlighting; it strips away 95% of Vim's power. If you make insert mode your default, then there's really no reason to be using Vim at all.

Vim is the type of application that expends very little effort coddling new users and instead focuses on being as flexible and powerful as possible for the veteran. That means its reputation for being difficult to learn is not entirely undeserved, but the majority of users who do surmount the learning curve grow to appreciate Vim for its peculiar style, in spite of the initial difficulty it brings.

The other problem with the 'insertmode' option, of course, is that the sort of user who would want to do such a thing is the least likely sort to know that such an option exists or how to activate it.

In terms of usability yes! But how many people would then just stay in insert mode forever, without ever understanding the depth of vi?

Most programs are about getting results now. There usability is most important. But some programs (like vi) are about getting extremely, awesomely better results later on. These tools need the student/user to be in the valley of pain for a long time that they can actually reach this point of enlightment. I would argue that such kind of program also needs to get rid of users, who don't have the motivation or persistence to stay until a certain point of enlightment. Giving up on vi is good for the people who do. They probably wouldn't need this kind of power anyway. And those who desperately want and/or need it will eventually come to that point of understanding the other modes and commands of vi in the end.

I think that for a long time vim or gvim on cygwin used to do exactly that (I could be misremembering here). It's literally just an addition to the vimrc file, so I've personally set up a few people's installs to do that if they asked. (Along with other handy vimrc things.) But I really don't think it's any good. In order to save or quit you still have to return to command mode (unless you're using gvim all the time), and I edit more than I insert for non-new files (that there's a difference surprises people), so you're not really buying anything. Explain the command mode, some basic editing commands, how to get to insert mode and back (perhaps even adding an imap instead of using escape; I like 'jk' myself), and let people use it for it and not just a notepad substitute.

You use Vim more effectively when you stay out of insert mode as long as you can.

Vim is _horrible_ if you stay in insert mode for long periods. In particular, it messes up the undo/redo feature.

Is it a good or bad sign that I'm starting to see a lot of stories repeat on here? I installed Ubuntu on my work machine last friday and I was just looking at this earlier this morning (I had saved this the last time it was posted).

I remember that the question was posted here before. This thread is focussed on one single answer of this SO discussion. First I was surprised, too. But now I think it is really great, because in this answer is so much more then what is connected to that question.

It took me far too long to really start using vim. I have to say, though, that as an avid user now I find it really annoying to find dw yy p :q and :w in the other editors I have to use on other machines. It does take discipline, though, but it is really FUN. How awesome is it to find some really sweet new key combination you didn't know existed? I almost never seek out the obscure settings of newer IDEs yet I often randomly search out new key combinations for vim. Love it.

This article captures the one thing about vim that took me the longest to "get", and which proved the most powerful once I did: vim has a rich set of movement commands, and a pile of commands which operate on those movement commands. Putting the two together gives a huge set of useful commands with a simple two-part form.

I have been enjoying using Vico for the past month or so, a pretty Mac face on vi, with extras like support for Textmate Bundles. The mac-ness of the interface helped me through some vi adjustment rough spots, and now I'm extremely comfortable doing almost everything the vi way.

Yes, I get it: some hackers of lore kept adding magic commands to the unix line editor until it grew into a stand-alone editor. Still doesn't appeal to me. Too many arcane keystrokes to do simple edits.

Simple edits require understanding 'i' to get into insert mode, 'v' to start selecting text, 'esc' to get out of either, 'y' to copy, 'd' to cut, 'p' to paste. Type ":wq" to save and exit.

There, you're all caught up.

What about things I know how to do in every app I ever use:

Cut, Copy, Paste, Find, Find Next, Replace, Load, Save, Print, New Document, Undo, Redo.

All of those things are standard in all mac apps, except vim of course.

It occurs to me (just now, so this might be a poorly thought out point), that vim (and emacs) can be viewed as the 'anti-unix'. Unix is designed around tools that fit together in a coherent manner. vim and emacs are huge worlds, uniquely designed to be nothing like anything else.

If you install MacVim all those standard things (except maybe find, but if you know how to use grep you know how to use find in vi (and if you don't then I can't really help you -- every programmer should know how to use grep, period)) are included in the menus to help you get acclimated.

As for design, Vi is a perfect example of Unix design. It's a text editor. It does one thing and it does it well: edit text. Some may disagree but I also think that Emacs is a good example of Unix design. It does one thing (interpret elisp) and it does it well. By the way, at it's core Emacs is an emacs lisp interpreter, not a text editor (despite misconceptions).

> By the way, at it's core Emacs is an emacs lisp interpreter, not a text editor (despite misconceptions).

While this is very true, it should also be mentioned that Elisp is a lisp designed for writing text editing tools.

(Die-hard lispers will cry blasphemy here; I realize that you could get the same effect in $lisp with a proper set of macros. I maintain that the distinction is not relevant as lisp blurs language and library).

tl;dr - Vim's GUI features are different (arguably better) than your Windows-ey conventions. If you want to get started with your "old" key shortcuts, get started with "evim" that ships with Vim.

Cut, copy and paste work a bit differently in Vim. There's a whole lot of clipboards (called "registers") in Vim, some of which have a special purpose. This is a very powerful feature but it doesn't work like the rest of your apps do so it may be misleading at first.

Find and replace is another feature that's not so easy to get started with in Vim, but, again, it can do regex matches and a whole lot more than your regular text editor can.

Vim has also got a neat undo feature, which actually stores a tree-like history.

New document, save, print and others can easily be found in just about any Vim GUI.

If you want a smooth start with Vim without having to learn everything again, you can use evim (bundled with default Vim) that uses all these Windows-ey "default" keybindings.

It's also worth mentioning that most of Vim's keybindings are default keybindings in Unix since the dawn of man (before Ctrl-S was ever used for saving anything). E.g. j and k for scrolling up and down, / and ? for searching, etc. For example they work with the "less" pager in Unix.

>What about things I know how to do in every app I ever use: Cut, Copy, Paste, Find, Find Next, Replace, Load, Save, Print, New Document, Undo, Redo.

And variants of course

* Cut - d

* Copy - y

* Paste - p

* Find - /

* Find next - n

* Replace - s///

* Load - e

* Save - w

* New Document - e

* Undo - u

* Redo - Ctrl + r

I'd call those pretty standard.

You would call those standard? What other applications use those?

They've been standards in Unix before Microsoft existed.

GGP said that those functions come standard in other applications. These functions do come standard.

FWIW, ed uses a lot of those.

And, as we all know, "ed is the standard editor". QED!

You won't hear any defense from me for Emacs, and Vim is certainly very debatable, but Vi is as UNIX as it gets: http://pubs.opengroup.org/onlinepubs/9699919799/

And expecting Vi(m) to use whatever shortcuts are standard for Mac applications is of course absurd. It isn't a Mac application, it's Vi.

All those features are in Vim. Unless your complaint is that the keystrokes are different from what you're used to on the Mac, in which case you should try googling "mac vim": http://code.google.com/p/macvim/

Certainly they are all in vim, I wouldn't suggest it can't do all those things!

But, I have to use lots of programs every day, and my "muscle memory" allows me to get a lot of consistent functionality out of all the programs I use. Whenever I've taken up vim, I've started having trouble with Eclipse/Chrome/TeXShop/etc...

Many people's solutions to this problem seems to be:

1) Use vim for everything or; 2) Make everything use vim shortcuts.

Neither of these appeal to me.

press i, use the regular keys?

vi's goal is not to simplify the simple tasks, but instead to complicate them to simplify the more complicated ones and allow the really complicated ones to be edited at all.

A thing that nobody ever seems to mention which unsettles me far more than learning key commands or modal behaviour in my brief tryouts with Vim is how its cursor visually highlights a current character rather than a point between characters like every other editor I've ever used.

Say I have a line as follows:

In other editors:

  to delete "abc" from the left:
   put the cursor on the a
   C-d C-d C-d

  to delete "abc" from the right:
   put the cursor on the character after the c (the d)
   C-h C-h C-h

  to delete "def" from the left:
   put the cursor on the d
   C-d C-d C-d

  to delete "def" from the right:
   put the cursor on the character after the f (the EOL)
   C-h C-h C-h
Symmetrical and consistent, to my mind.

In Vim:

  to delete "abc" from the left:
   put the cursor before the a

 to delete "abc" from the right:
   put the cursor on the character after the c (the d)

 to delete "def" from the left:
   put the cursor on the d

 to delete "def" from the right:
   put the cursor on the f
The last case there is exceptional. It's a small thing, but not being able to put the cursor on a real or virtual 'end-of-line' character in Vim makes me feel constricted.

I think that the between chars cursor model is simpler because you then have two choices: act on the preceding chars (thus, delete with C-h or <Backspace>) or act on the succeeding chars (thus, delete with C-d or <Delete>). By contrast Vim is more complicated because from the current character you have three choices: act on the preceding chars (thus, delete with X), act on the current char (thus, delete with x), and the principle of 'completeness' suggests a third: act on the succeeding chars - which AFAIK is not available in Vim and so it feels lop-sided to me.

Ironically I think that it's my 'programmer head' which makes the between chars model appeal to me more, as I think of the file as a bunch of bytes (well, maybe multibyte characters) and the text editor as a glorified hex editor, and I just want to choose a position and insert or delete chars regardless of whether they're alphanumeric, LFs, or whatever. Whereas Vim's model of manipulating words, lines and sentences suggests to me a fit with people writing in human languages. Why, non-geeks should love Vim, perhaps except for all the key commands to learn; one imagines an alternate universe where the common keyboard evolved with two Return keys instead of one, labelled "Open new line above" and "Open new line below", and other Vim-inspired niceties - and I wonder whether your archetypal 'grandmother' might find it easier to write letters on the computer in that world than her current futzing about in Microsoft Word.

I think from a programmer standpoint, I'd prefer to deal with the text directly instead of with some abstract space between characters.

I see your point though, it is different. It does take a little getting used to, but if you slowly teach yourself the motions you'll learn it unconsciously.

As for your example, you're running into this problem because you are manually placing your cursor. If you watch someone who uses vim, they almost never use the keys hjkl, or even x. When you type w to get to the next word, or when you search for something, the cursor will be conveniently placed for whatever kind of deletion you plan on doing. x is for deleting one character, if you ever want to delete more, you move to where you want to start, then use a motion and delete. For more precise control enter visual mode and delete. But never hit x three times in a row and stop to think about whether the cursor is going to shift left or right after the first x.

Vim does have a concept of words, sentences, and paragraphs, but that's because it's not a programming editor, it's a text editor. It also has a concept of lines, braces, parens, and angle brackets. That's because programming is a common text editing exercise :)

Yes! I know what you mean and it annoys me sometimes, too. Particularly:

1) Hitting escape pops you out and left. So insert - escape - insert - escape, etc, gradually moves the cursor left. This feels weird to me. Everyone calls it "insert mode", but perhaps it would be better called "append" mode, because append is the exact opposite of command mode, in the sense that a - ESC - a - ESC, etc, leaves you in place.

2) It makes it annoying to delete the last n words I typed. I want to go, "oh, mistake! ESC db..." but that leaves the last letter hanging around. I recently realized you can do "ESC daw...", at least.

These are design decisions which were built in eons ago; there was a valid reason for it that was explained to me once but I forget now.

Anyway, there is this in the default vimrc:

  " Professor VIM says '87% of users prefer jj over esc', jj abrams strongly disagrees
  inoremap jj <Esc><Right>
So you can use jj (or any other mapping) instead of Esc and get the behaviour you want.

Are you using vim from inside a terminal? If you use the graphical version of vim (gvim), the "between two characters" cursor is used in Insert mode and the "highlight the current character" cursor is used in so-called "Normal" mode. (In a terminal-based vim's Insert mode, visually the cursor highlight a single character, but it acts as if it were between the highlighted character and the character to the its left.)

I think most people's problem with vim and vi is that they just don't feel like crossing the river to get their water.

Or maybe their Kool-Aid :)

> A sampling of more advanced tricks

I don't do tricks.

I agree. I know my view is very unpopular here, but I really don't think an editor that requires that massive block of text to understand is good. I used vi (not vim) for at least 10 years. The power of ed is what makes vi powerful, but if that's all I care about, I could just use ed (especially Plan9's ed which is more GUI than your old ed).

I switched a couple of years ago to acme (http://acme.cat-v.org) and sam (http://sam.cat-v.org). Sam is a graphical version of ed, just like vi is supposed to be but for me sam is better. It's really GUI (unlike gvim which is GUI patch on vim) and it does everything a modern ed (from Plan9) does and much more (structured regular expressions).

Both editors were designed by Rob Pike and are used today by key UNIX/C figures like Ken Thompson, Bjarne Stroustrup, Dennis Ritchie and Brian Kernighan.

All things considered, I'd still take vi(m)? over emacs anytime :-).

"I really don't think an editor that requires that massive block of text to understand is good."

Isn't that a bit disingenuous? From what it sounds like, you were probably able to become quickly proficient with sam and acme because you were experienced with vi and ed.

It doesn't look like those editors are without any need for documentation. http://doc.cat-v.org/plan_9/4th_edition/papers/sam/

You don't need to know ed command language and regular expressions to use sam or acme. All you need is a mouse. Knowing them would make a huge productivity boost but you can start using them gradually.

Yes, you need documentation. How much though? I'd say very very little compared to traditional editors.

It's a matter of taste. Many people here prefer to use the mouse as little as possible, and from what I understand, that's not the direction sam has taken.

Count me among the "no mouse" people. I'm a touch typist, and constantly moving my right hand back and forth to the mouse just slows everything down to an unacceptable degree.

Exactly, mouse usage is pretty much required in Sam and Acme (and Plan9).

ed (especially Plan9's ed which is more GUI than your old ed).

'More GUI' because it added the b[rowse] command [1]? That's a bit of a stretch!

[1] http://plan9.bell-labs.com/magic/man2html/1/ed

Ah, no, sorry. It's more GUI because Plan9 terminals allow editing everything on screen. So I can type my text in ed and then use my mouse to position the cursor somewhere up, select text, and make a change.

Perhaps I should have phrased it differently, if all I cared about was ed commands I could have used Plan9's ed in conjunction with a plan9 terminal, like 9term.

In UNIX I use plan9port which has a port of ed, and 9term, a terminal that acts like a Plan9 terminal.

> So I can type my text in ed and then use my mouse to position the cursor somewhere up, select text, and make a change.

No you can't, not in ed on Plan9.

Sure you can. Turn on rio's hold mode.

Yes you can type away all you like but ed only reads commands from the prompt, just like a line orientated terminal.

You cannot unread what was already read but with hold mode you can have a two-dimensional view of what you type and edit it at any point that wasn't read yet, that means since you started hold mode.

> Even when there are newlines in the output text, 9term will not honor reads if the window is in hold mode [...] Some programs automatically turn on hold mode to simplify the editing of multi-line text; type ESC when done to allow mail to read the text.

Perhaps he means Sam, which is a kind of GUI ed

Funny you should say that. The screenshot here http://en.wikipedia.org/wiki/Acme_(text_editor) is my screen

I bet you do, though - my experience of learning anything to a reasonable depth has been that I developed short-cut ways of doing things that are necessary but laborious to a beginner.

Maybe vi has a higher-than-average density of tricks due to its steep learning curve, but once you know them it's very capable.

Actually it's just that I'm not a fan of editor modes.

Why should I have to grok a text editor? Up, down, left and right should get me around and if they don't, I'm not the one who's wrong.

"You guys just don't understand why I eat dirt. I'm on a higher plane of existence and you just don't get it."

Up, down, left and right should get me around

This works fine in vim. It's not suggested practice since moving your hand over to the arrow keys is slow, but it works like any other editor.

It turns out that moving the cursor using the mouse is dramatically faster than using the arrow keys, and moving using incremental search (Raskin's LEAP) is dramatically faster than that. So while you're eating your dirt off the arrow keys, the rest of us are already at the point where we want to make our edits, we've already made the edits, and we've rerun the test suite with another keystroke to verify that the edits fixed the bug. See you later, I gotta go to lunch. Have fun with your arrow keys.

Moving your hands from the keyboard to the mouse (and back) takes longer than getting to where you want using Vim navigation on the keyboard. You can also use intelligent movements (e.g. f" = to the next " on this line, or /foo = to the next line with foo or 362G = to line 362) instead of pounding the keyboard like crazy.

Yes, I'm sorry if it wasn't clear that was what I was saying. Thanks for the examples. I also use t a lot, but more with c, e.g. ct. or ct).

Good post, and worth reading if you're stuck with vim and don't like it.

But, reading this reminds me of how much I like GUIs. Yup these movements are great. I get the appeal of turning selecting text into a dumb programming trick, I'm sure it makes you feel very clever and productive. Of course I can do all this stuff and more without even consciously thinking about it using a mouse.

Go do multi file grep in BBedit in front of an emacs jock one day. Look what I can do by finding a menu item!

Douglas Adams used to talk about how powerful formatting features in word processors were a great way to procrastinate.

> Go do multi file grep in BBedit in front of an emacs jock one day.

Is there something it does that's better than M-x grep? I'm asking honestly, not to be snarky.

And either way, it's not that menu items are bad... it's just, well, I've been using Emacs for ~20 years now. Across god knows how many different platforms, installations, and technology tool chains. How many times have you re-found that menu item? And how does their menu item differ from the one in (TextMate|VisualStudio|XCode|Eclipse|...).

If BBedit is the only editor you've ever used or will use, great. But honestly, I don't want to find move next paragraph, spell check region, or reindent block ever again. They may be in the editor, in some menu somewhere. It may even be similar to the place I found it last time...

> Go do multi file grep in BBedit in front of an emacs jock one day.

Using ack and the emacs mode http://nschum.de/src/emacs/full-ack/ I search a hundreds of megs in source in ~5 seconds. I have yet to think of something that there is not already an emacs mode for.

> Of course I can do all this stuff and more without even consciously thinking about it using a mouse.

One of the reasons vi/vim is so much faster for me is that there isn't a need to move between the mouse and keyboard with the requisite hand/eye/mouse/re-home coordination. Yes the key combos are bizarre, but so is the querty keyboard layout for that matter. Once you learn it, your fingers act as a direct connection between your brain and the editor. A mouse can't do that.

Once Apple released the Magic Trackpad, all my mouse annoyances disappeared. It's always right there, and it has a tactility on par with keyboards.

> querty

Ooh, I think we found part of your problem.

Go do multi file grep in BBedit in front of an emacs jock one day. Look what I can do by finding a menu item!

You mean something like this: http://i.imgur.com/0pieh.png ?

It has been almost 10 years now since GNU Emacs got GUI, and XEmacs (as the name suggests) had it even earlier, and yet many people still believe that Emacs has only console interface. I think the main reason is that most Emacs users (me included) turn off menu and tool bars so that they're not distracted by them -- almost nobody uses them anyway, because moving hand from keyboard to mouse and clicking through menus is so annoyingly slow.

There are many uninformed opinions in this thread, about Vim, Emacs and heavyweight IDEs like MSVS or Eclipse as well. Please, refrain from bashing things you do not know, because it usually sounds silly for those who do know them. But, yeah, all's fair in love and war, especially when you're fighting for your loved editor.

> Go do multi file grep in BBedit in front of an emacs jock one day. Look what I can do by finding a menu item!

Isn't this just using ack? (:Ack in vim, not sure of the equivalent in emacs)

You might find this binding useful. Does an ack on the word your cursor is currently on.

:nmap <C-f> :!ack <cword><CR>

Vim's :grep does what you want, and also displays the results in a nicely navigable form in the quickfix list or the location list.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact