How a Vim user converts to Emacs | Hacker News Reader

How a Vim user converts to Emacs

bradbeveridge.wordpress.com

92 pointsgnosis66 comments

I've always thought that the whole vi(m) vs. Emacs "war" is a false dichotomy. I'm an Emacs guy myself; I haven't used vi(m) a lot, but from all I gather it's a fine editor. The real "enemy", if we need to use war-inspired vocabulary, are editors like nedit, Kate, ScITE, and maybe even Textmate (boy am I going to get told off for this!)

Emacs and vi(m) are great editors today, but imagine how much even greater they would be if all those people pouring hundreds and thousands of man-hours into projects like Gedit, JEdit, KWrite, Medit, etc. would have instead put their efforts towards improving the true editors!

Disclaimer: I haven't really used those other editors a lot and I'm sure that each of them has something going for it.

Also, I know how much fun it is to work on something challenging, like a text editor, even if (or exactly because) there are already established "solutions".

Finally, a few alternative editors are genuinely useful, such as nano - it might be inferior in pretty much every regard to Emacs, but it's not possible to shrink Emacs to nearly the size of nano so it does seem to serve a valuable purpose for when disk space or memory footprint is an issue. Cue the Eight Megabytes And Constantly Swapping jokes.

EDIT: and yes, Emacs/vi(m) are not necessarily the be-all, end-all of editors for all time to come; maybe one of those alternative editors will one day prove to be superior. All those other editors just remind me of the phrase "Those who don't understand Emacs/vi are condemned to reinvent it, poorly"... err, or something like that.

> Finally, a few alternative editors are genuinely useful, nano - it might be inferior in pretty much every regard to Emacs, but it's not possible to shrink Emacs to nearly the size of nano so it does seem to serve a valuable purpose for when disk space or memory footprint is an issue.

I'm an emacs user too, and I now use zile ( http://www.gnu.org/software/zile/ ) instead of nano. The ability to use the same keyboard shortcuts that i'm used to is a godsend.

There is also mg: http://en.wikipedia.org/wiki/Mg_(editor)

You don't need nano when you have vi on every install anyway.

The gp is an emacs user and zile is a bare bones emacs. If you are a proficient emacs user going to vi is going to be torturous even on small projects. I am a vim user and I see why the gp would want to skip vim and use something comfortable.

> The real "enemy", if we need to use war-inspired vocabulary, are editors like nedit, Kate, ScITE, and maybe even Textmate (boy am I going to get told off for this!)

Don't forget Eclipse.

Neither Windows.

All those web browsers, IRC clients, email programs. You can do pretty much everything inside an emacs.

If you ever draw a Venn diagram of Windows users and Emacs users, you'll see the intersection of both sets is vanishingly small.

I agree with your "too much fragmentation" argument. Although I think a better solution would be this:

1. Define a common API to text editors. It would have stuff like "change text at" and "highlight line" and so on. Going the other direction there would be a set of well defined events like "text changed" and "do X", and so on.

2. Convince tool makers to write to this api rather than a specific editor.

3. Enjoy awesome source tools from any darn editor you want.

(Also, IDEs don't go away, they become the gui layer in editor/plugin interaction. This is not a small role!)

wasn't this what elisp was for, albeit it is very emacs centric.

Elisp is the inverse of what I am talking about... it is a special purpose language to take advantage of a specific editor. I am talking about a well defined generic interface that allows for all editors to tie nicely with code-tools.

> Emacs/vi(m) are not necessarily the be-all, end-all of editors for all time to come; maybe one of those alternative editors will one day prove to be superior

Some of those editors are already superior. Imagine you convince <insert name of computer-illiterate relative> to switch to linux. If they need to edit a text file, are you going to recommend Kate/gedit or Vim/Emacs?

I would wager a lot more non-programmers use text editors than programmers. Of course programmers use text editors a lot more often, but still the importance of those other editors should not be underestimated.

> Some of those editors are already superior.

To vi(m)/emacs? An example?

They're easier to use.

No, they're easier to get into if you're used to Notepad.

Not even that. For instance, gvim comes with an "easy mode" (just start it as "evim").

In this mode, it acts very much like Notepad (you're automatically in insert mode, and you can just use the File menu to open files, save, and exit).

I'm not sure how much having this mode buys vim, however, as there's no gradual way to progress from "easy mode" to more advanced vim use. Except for the syntax hilighting it offers, its users might as well just be using Notepad, nano, pico, or what have you.

I find this response baffling. Are you seriously claiming that normal people (non-developers) would do better using Vim/Emacs rather than a Notepad-like editor? Or that most normal people aren't used to Notepad-like editors?

I despair...

There is a difference between Vim 'the concept' and Vim 'the program'. I like the first one, but I couldn't care less if I am running vim itself, emacs with Viper mode, Vimperator or what have you. To me a person who is running emacs with Viper mode is still a vim/vi user.

How far off is viper mode from vim, anyway? Anyone who uses it regularly care to share how close it gets you to vim-level speed?

From what I understand, viper is not intended to be a vim emulator, but rather a vi emulator (if you could even call it that).

As a long-time vim user switching to emacs (just to edit lisp code), viper mode does not feel very comfortable or familiar.

Sure, the basics are similar. But to get a good handle on how to use it and configure it to your liking, you have to read a ton of documentation. Also, configuring it effectively seems to require being familiar with many emacs concepts and ways of doing things.

A vim user is really going to be lost until he does a ton of reading on this stuff. And even then, it's going to take him a long time to feel comfortable with it.

And that's not to mention that by default viper only works in a very limited number of emacs modes. You can configure it to work in more modes, but then you'll loose out on a lot of default emacs features that are tightly integrated in to the regular configuration of those emacs modes.

You may be able to reconfigure those modes to allow them to be used more naturally in viper, but that's going to be a lot of work (and, again, require you to learn a lot about emacs).

So if you're a vim user switching to emacs, don't expect viper to make you feel at home. Vimpulse extends viper to be just a bit more like vim, but it's really just a thin gloss over the basic viper functionality. Even with vimpulse, some of the basics may be the same, but you're still going to be very far from vim.

And even if you do spend the time to learn enough about emacs and learn enough about viper to customize it to be much more like vim, you're still never going to be able to replicate one crucial aspect that makes vim such a joy to use: its thousands of plugins.

Sure, emacs has its own packages and extenstions that probably do many of the same things (arguably, for some of them, maybe even more). But if you use them you're going to be essentially just using regular emacs, with a vi or vim gloss over it.

If you're a vim user and you like, know, and regularly use many vim scripts and plugins, those aren't going to magically become available for you to use in emacs, even with vim and vimpulse. If you need any of the functionality of these extensions in emacs, you're just going to have to find the emacs equivalent and learn how to use it. This is going to be yet another major drain on your time.

Of course, if you're committed to really making a complete switch to emacs, it might be worth your time. But if, like me, you only want to use emacs for a limited subset of things, you're probably going to have to learn to live without the ease and convenience you get from your scripts and plugins you have in vim (unless you're willing to put a major amount of time and effort in finding, learning and configuring the emacs equivalents).

Emacs isn't vim. I think vimpulse gives the most essential bits of vim, while the other bits can be replaced with emacs functionality without a loss of efficiency. I don't miss any of my vim plugins. The only plugin I use that brings emacs closer to vim is viper/vimpulse. Vim still feels slightly (maybe 5-10%) slicker when editing text (I'm a long-time vimmer that moved to emacs a few months ago). In return you get (IMHO) superior indentation, better integration with external processes (such as debuggers and REPL sessions) and easier customization.

What exactly is it that you miss from vim that you're not getting in emacs? Is it only a generally decreased feeling of efficiency? Because that definitely went away for me once I learned to leverage and customize emacs.

Found an article on switching to Vim after two decades of using Emacs: http://pinard.progiciels-bpi.ca/notes/Thoughts_on_editors.ht...

And another one on converting to Emacs from Vim: http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs...

I've read that a few Vim users have switched to Emacs to take advantage of ENSIME, which is a really nifty Scala development environment.

Org-Mode is another reason I've heard for switching.

I'm one of the people who switched from Vim to Emacs due to Org mode, and I've never regretted the decision. In the past year, I've used org-mode to take all my notes in class, write documents and as a task manager. All in all, the gain in productivity due to org-mode massively eclipses the time it took to un-learn vim and become decent at emacs.

You can also write and tangle code in it for literate programming purposes. You can also read-in values into the programming code in the org-file and return results to it as well.. so you could technically run your unit tests in the file and return the results in a nicely formatted org-table. :)

You just can't do that stuff with vim. I used to be a really hard-core vim guy but I eventually switched. Now I'm an emacs-or-nothing guy. :)

https://github.com/hsitz/VimOrganizer

Vims answer...

I recently switched from Vim to Emacs and org-mode was the selling point. But Emacs Lisp and M-x tetris are also good reasons I suppose.

In my case, I'm learning Emacs after ~15 years avoiding it. I use a combination of Vim, Eclipse and Netbeans for enterprisey Java, but after that many years of a fixed mindset, I'm trying to reinvent myself and I'm trying both Clojure, JRuby and Git; Emacs has great modules to integrate them with ease.

Currently I don't have the fluency I had with Vim but I think the effort will pay itself on the long run. The key is to practice and use Emacs as much as you can everyday.

Vim has great text navigation features but nothing I can't do with a mouse as fast or faster. With a mouse I can scroll two pages, highlight and replace a function in about two seconds. It would take me far longer to do this using keyboard shortcuts.

Most of my time spent coding isn't spent on navigation of text files anyway. Most code is very modular and I switch between text files frequently. In an IDE, you have a navigational tree of your files from which you can find and switch to a different file in about two seconds.

Does anyone have any evidence that vim is actually faster at these two things, and not just hype? If not evidence, at least solutions to the above two problems which you think are faster than using an IDE?

     With a mouse I can scroll two pages, highlight and replace a 
     function in about two seconds

I really don't believe you. Scrolling itself takes 2 seconds minimum. You also haven't mentioned the time it takes to open that second file (to open a parallel window with another file costs me 1 keystroke to open the window, another keystroke to invoke "find", and 4-5 keystrokes to type a keyword).

In Emacs scrolling, highlighting and cut/pasting that function does take me at most 2 seconds (the total time): mostly because I don't have to scroll, almost never, as I jump through the file by doing searches, which in Emacs are really cheap and intuitive, with great shortcuts.

Highlighting is also a lot faster for me:

You have to drag down the mouse cursor, while holding the left button, being careful to not select too much or less. That alone can take 2 seconds. What I do is to get to the start of the block (again, shortcuts for jumping in Emacs are great), mark the start of a selection, then jump again (here I don't even have to search, since I can jump to the closing bracket). So highlighting a block costs ~ 6 keystrokes (including search), and takes me less then a second because these shortcuts are already hardwired.

Also, when copy/pasting text Emacs remembers everything you ever copied in your current session (the kill-ring); if you copied something a couple of minutes ago, there's no reason to return and copy it again. This and other niceties like ... being able to UNDO anything, even previous UNDO operations, or being able to UNDO operations only in a selected region of text, make it the ultimate text editor for me.

Also, working with windows in Emacs could use some work, but buffers are great.

What could be easier when working with windows?

For me this is hard to understand. Either I haven't seen anyone who is able to 'mouse' as fast as you can. Or you haven't yet seen someone who is really good at Vim.

I didn't understand until I saw one of my professors, who lives in vim, work on some code. It was mind-bending. I can only imagine that when watching me type code (at the time) he must have felt how I feel when I watch my parents use the internet.

As a man who lives and breathes vim, the answer to your question is most certainly yes. Watching other people code without mastery of their editor is heartwrenching.

Anyone know of screencasts with keystrokes (I don't know how) that would reveal that mastery?

Screencasts unfortunately won't do it. Learning to touch type (not 'I have my own system' touch-typing, I mean 'Mavis Beacon Teaches Typing' with all ten fingers where they're supposed to be) and then spending a couple of minutes every day learning a new command or two for a few months is more realistic IME.

http://vimcasts.org/

Just went searching on the internet for a vim demo video and found this:

http://www.youtube.com/watch?v=QNAXa0W4OFg

Also, if you have a Mac (or most versions of Linux) you can also access an instant tutorial by typing "vimtutor" at the terminal.

For those of you looking at this video to get an idea of the power of vim in the hands of a serious user: although this person is using it quickly, he is nowhere near a master. The key to vi is that any time a user is pressing the same key multiple times, there is a faster way. In this video I often see the user using the same keystroke multiple times to get from here to there. Most notable, he routinely does this to get from his cursor position over to a spot later in the line (such as when changing the word "test" which was in quotes), or to get to the end of a section (such as when he was copying then changing the body of a function).

If you're a vi user or an aspiring vi user that wants to get faster, then start consciously looking for times that you're pressing the same key more than about twice. Each of those times is almost certainly an opportunity to get faster.

So in particular from watching the above video, these are two shortcuts that I use all the time that the video maker did not use. Let's say you have a line of text like: Img.save('roberto.png') and you want to change it to x.png. If your cursor is at the start of the line, you would never arrow over there. You would type fr (find r, which would move your cursor to the r in Roberto). Then you would type "ct.x" which means change until we get to the period and replace it with the letter x. It sounds complex, but after a while you just do it without thinking, and it's faster to type 5 keystrokes with 2 hands than a bunch of repeated keystrokes with one hand.

Similarly, the } and { keys should be used to navigate to the next or previous blank line, which could have been used in this video to change the body of those functions in a couple of keystrokes instead of the arrowing around and highlighting we were seeing.

I'm not trying to pick apart the video, the person is clearly fast and effective. The point is just that vi gives you the flexibility to always get faster if that's what you're into.

We can shave another keystroke off your example.

Instead of "ct.x", "cwx".

Brilliant, exactly.

Another important point here: A big benefit of doing changes like this is that vi has the special command "." which repeats the last change. With a single keystroke, it makes the same change you did last.

In practice this comes in handy quite often. Let's say that I have a program which generates a bunch of images. Let's say it's generating 4 images, and 2 of them are thumbnails and 2 are big versions.

img1.save('x-th.png',100) img1.save('x.png') img2.save('y-th.png',100) img2.save('y.png')

I want to change the thumbnails to .gif. I can't just use search and replace, because I only want to change 2 instances. (Technically I could with a regex, but forget about that for a moment.) I go to the first one I watch to change, use 'cwgif' which changes the png to gif. Then I navigate to the next one, and just press period. The period key is one of the monster productivity boosts you can get from vi.

For me it's about convenience rather than speed; I find myself switching between navigating and editing a lot, not having to switch between the keyboard and the mouse is very convenient.

That said, I think I'd perform your example-interaction faster with the keyboard and my knowledge of the shortcuts in Vim. It's probably due to accuracy (with a Vim movement command I know exactly what is targeted -- no need to aim with the mouse).

Merry Christmas!

Maybe all of the hardcore vim purists will hate me, but I use the mouse a pretty good amount when I'm using vim. I'd say I do about 70% navigation with the keyboard and 30% with the mouse (mostly scrolling).

Also, I had to post the famous quote that "emacs is a decent operating system, lacking only a good editor".

"emacs is a decent operating system, lacking only a good editor"

viper/vimpulse solves this quite neatly. I find the mix of emacs with viper+vimpulse to be the best of both worlds: The efficiency of vim when doing fine-grained text manipulation and navigation, and the completeness of emacs for integrating my workflow (running shell processes, switching buffers and finding files with the built-in fuzzy matching ido-mode). It's just so much better to have the terminal in a split window, interchangeable with code buffers, than having to alt-tab all the time. Emacs brings vi to the whole workflow, in my experience. All the little things, like selecting and yanking text to and from shell buffers (all with vim keybindings), just make it feel good. Also, the indentation is great, keyboard macros are much better (you can record commands other than simple keystrokes, e.g. searching) and the language modes just seem to understand their subject languages more "deeply" somehow.

vim and emacs + viper/vimpulse are both programming environments that implement vi's modular editing philosophy. It's the vi editing model that I couldn't possibly leave behind me, not vim. I might even be able to survive a modern "IDE" were I able to use well-implemented vi/vim keybindings :)

by function you mean a function call? two pages down, and replace it's about 8 keystrokes (ctrl-f-f to get to second page, say /<first-two-chars> to get to the function, cw to change it) does that take you more than two seconds? Also, you'd probably just do search instead of moving down two pages, and then replace (/<first-three-chars>cw). I'm no vim power user though, so I can't say if there is a better way, but it is faster for me.

I believe in full featured ides (because of features like integrated debuggers, refactorings) but not because of the mouse, so even if for example eclipse has a file tree, I usually open a class by shortcut+<start typing classname>enter, isn't that faster than navigating a tree?

The faster way would be if you used ctags and had your cursor already on the function name. Then, simply typing:

  CONTROL-]

would take you to the function definition (wherever it was, in the same file or in a different file), and:

cw

would change it.

Three keystrokes in total.

There's no way a mouse user could do better. Especially as he'd need to type "c" anyway, to start changing the name of the function after he'd selected it with the mouse.

So the difference would really be in two keystrokes vs moving your hand to the mouse, scrolling down, using some error-prone and slow way of finding the function name visually, followed by a selection of the function name with the mouse.

A touch typist should easily be able to type those two keystrokes in the time it would take to simply move one's hand from the keyboard to the mouse.

So however long it takes to perform the rest of the needed operations to find and select the function name by mouse along with moving one's hand back from the mouse to the keyboard would be time wasted in comparison to the keyboard method. Time that could be more productively used in continuing to edit something else.

Now multiply that time waste by 50 or 100 times you need to do that per day, the hundreds of days you spend editing per year, and the decades you spend editing in your life.

And that's not to mention the more complex editing tasks that are simply impossible to do with the mouse (without breaking out the virtual keyboard that you'd need to click on with the mouse, which would be a completely ridiculous way to edit if you had a real keyboard in front of you and were capable of using it).

You'd be amazed how fast you move around and do edit actions once VIM shortcuts become second nature.

I think this is purely a cultural background issue.

People with systems/sysadmin etc. background have been mentored and thus grew up to use vi (it is available from any unix terminal prompt and is not an OS in itself™).

People who grew up in comp/sci/phy used to see emacs as their first editor, and used it mostly graphically.

I think switching is done either as a switch given because of the evolution of one's functional role -- be it involuntary or voluntary (latter just for fun or self improvement).

Does anyone here switched from Emacs to Vim? Comments?

I had a progression like this:

Emacs -> Vi(m) -> Emacs

When I started programming in college it was Lisp and C and I got a co-op working for a big defense contractor doing C and everyone there used Emacs so I used Emacs. I remember being very good at it at the time.

Then I started to do quite a bit of sys admin work along with Perl and web scripting during the dotcom days and switched to Vi as I found it much quicker to use when doing sys admin tasks and Perl was quite simple as well.

Then I started to do enterprise Java development. I call these my 'dark years'. Eclipse, IntelliJ and others but with Vi keybindings if I could find plugins for them (search and replace in Vi is great...love just hitting the '/' and beginning to type.)

Then I started to do some Erlang and Clojure and I Vi wasn't cutting it anymore. So I started to use Emacs again (this is about 12 years later at this point, btw) and realized I didn't remember anything. So I grabbed Emacs Start Kit on github, forked it and started to hack up an environment I felt comfortable in. Slowly It has been coming back to me, but in the time since I was out of Emacs there have been some good advancements.

At this point, I think I have the best of both worlds in that I know Vi(m) pretty well, have a really good .vimrc that I like and I also have an ability to use Emacs for non-trivial tasks and feel I'll be able to really use it in about 3 more months of steady use. The weirdest thing is trying to hit escape (or 'jj' as I've remapped it) in Emacs...

All in all, I think I will end up preferring Emacs for non-trivial tasks and still use Vim for basic text editing or sys admin tasks.

I do like both for their various strong points, but at the same time I have to say that both are quite annoying in other ways. I just have to learn to love their strengths rather than hate their weaknesses.

You raise an interesting point: what you're editing has a big impact on the effectiveness of the editor you're using.

When I first learned vi, I kind of hated it because I was editing code on an ancient system that used a COBOL-like language, in which most things were in upper case. Because vi's commands are all case sensitive, combined with the fact that I used capslock a lot for coding, it was kind of a pain. Also this language did not use a c-like syntax with punctuation, it instead used a lot of english words.

Later when I switched to editing C source code with vi, suddenly vi's quirks and methods of operation become far, far more productive than they were using vi.

I have, XEmacs -> Vim.

I had a very simple reason. I spend 4 hours a day in front of an editor, so I need something very powerful. I had standardized on XEmacs, but I had to stop when the pinky muscle strain got too bad (this was years after having remapped caps-lock to control). My hand would hurt when I got home.

I usually program in C/C++, Perl, and some XML & text editing, so I wasn't using Emacs' dynamic or programmable features much.

Vim is attractive because there's not really a need for modifier keys, just key sequences. Additionally, the great text navigation features are good when working with large existing codebases, it makes reading other people's code easier.

I kept going back to Emacs for XML editing for a while, but the mental overhead of keeping track of two systems is a bit much, and I found Komodo Edit a nice replacement (that incidentally also has a Vi-mode).

The only thing I really miss from Emacs is being able to "Ctrl-K" 3 times and pressing "Ctrl-Y" once to move 3 lines. With Vim you have to count the number of lines ahead of the operation, which is a real speedbump.

> With Vim you have to count the number of lines ahead of the operation, which is a real speedbump.

With Vim 7.3, a new option 'relativenumber' was introduced to help with this.

From :h relativenumber

Show the line number relative to the line with the cursor in front of each line. Relative line numbers help you use the |count| you can precede some vertical motion commands (e.g. j k + -) with, without having to calculate it yourself. Especially useful in combination with other commands (e.g. y d c < > gq gw =).

"The only thing I really miss from Emacs is being able to "Ctrl-K" 3 times and pressing "Ctrl-Y" once to move 3 lines. With Vim you have to count the number of lines ahead of the operation, which is a real speedbump."

V-jjj-x

If I understand you correctly. I don't speak emacs.

> The only thing I really miss from Emacs is being able to "Ctrl-K" 3 times and pressing "Ctrl-Y" once to move 3 lines. With Vim you have to count the number of lines ahead of the operation, which is a real speedbump.

I agree this is a big problem, and here are 2 ways I combat this in vi.

One way to combat this: Use } and {. These cursor controls in vi move to the next blank line. If you structure your source code such that you have paragraphs sections or blank lines between major operations, this works very well. Arguably, good code should have a brief comment explaining what or why something is happening, followed by somewhere between 1 and 8 lines that do the work. If your code follows this style, then the } and { keys in vi navigate that code ultra quickly. Say you've got 2 paragraphs that now need to go into an if statement, you press 2}>> and it just indented those lines for you, without you having to count how many lines it was.

Another way to combat the problem of counting lines is with named markers. Go to the first line and press mk. This creates mark k. Go to the end of the section you're interested in, and do something like >'k. This indents the code starting from point k down to where you're at.

I suppose you are a recent Vimer. I'd suggest to once in a while peruse threads offering Vim tips, such as in Stackoverflow. You might find some true gems in there. As noted by auxbuss, [shift-v jjj x] solves your issue.

That's the main thing I use visual mode for in Vim: to avoid having to count the number of lines. From the start of the block you just press 'v' then move the cursor to the end of the block; once you've got the lines highlighted, the yank and delete operations will automatically use them.

There are actually three visual modes in vim:

  v

  V

and

  CTRL-v

It's well worth your time to learn them all.

See

  :help visual-use

for more info.

Thanks! I knew about CTRL-v but didn't know about line-wise block mode ('V').

He doesn't :)

It's a shame he didn't keep writing: all three entries are from June 2007.

He now has RSI :(

This reminds me of one of the best real-life history log entries I have seen:

vi .emacs

Around 1990 I went through a phase of using vi for trivial edits, because I could finish them in less time than it would take for Emacs to start on the shared(!) hosts available to me. After that, the bounty of Moore's law let me keep one open all the time.

vim is a text editor.

Now if you are writting html you will open 4 different browsers in emacs?

You have a window manager for a reason.

Reply on news.ycombinator.com