Some thoughts on Emacs and Vim | Hacker News Reader

Some thoughts on Emacs and Vim

zuttobenkyou.wordpress.com

29 pointscodeup43 comments

Having to support what I write in production situations let me to choose vim over emacs long ago. The biggest con about emacs that's not mentioned is that it's just not _everywhere_. Even if I have to log into a firewall to make some emergency change, odds are even that has vi installed. When you start looking at doing embedded work this is even more of an issue. It's hard to rapidly iterate on a prototype when you have to make a change in your sandbox in order to use your editor of choice. YMMV of course.

"Vim’s Normal mode lets me fly around a document"

Isn't this just because he is more experienced in Vim? I'm not an expert in any case, but is it really true that Vim is that much faster (editing-wise) than Emacs?

I'm guessing that everyone's editor of choice would be the one they're most comfortable in. In other words, the one in which they've invested the most time into learning.

I use emacs for everything except to quickly jump around a file and edit it. Vim is super fast for this.

Emacs will also help you when your in weird situation because it is so powerful. One very simple example: we had some new machines installed recently but they didn't have our home directories nfs-ed onto them because the San was in a different network. With e-shell In emacs I could copy over my files without even opening a window to my home directories because emacs's tramp mode is built into the shell. It meant that I had autocomplete in my shell while working on a remote machine. Guys were ftping files clumsily over while I just had to use "cp" and the tab key.

Two other alternatives to emacs in this situation are sshfs, and mc's (midnight commander's) fish protocol.

true, but thats the whole point. You rarely need something other than emacs ;)

Assuming you use emacs in the first place. And not everyone does, or cares to. Especially when there are alternatives with a much easier learning curve.

That's like not keeping a multitool at home. I can go on and on about weird problems emacs's has saved me from.

But sure, google a solution, download and compile it, then learn it and fix your problem...

I'll just emacs's ;)

I dunno, I'm a longtime emacs user/addict, and I get the feeling that its actual editing commands just aren't that well thought out -- because of this, I've flirted with trying to use vim and vimpulse (an emacs vim emulator), but it's super-hard to get away from emacs once you're used to it...

I'd be interested to hear if anyone else has moved from emacs to vim. (Or thoughts of people who've gone the other way.)

I dunno, I tend to prefer the emacs movement keys over vim. I-search to move around in emacs, in combination with C+A+f/b is (usually) fairly fast - though a fairly good reason for that might be because I know the structure of what I edit. As for someone who moved from emacs to vim, I cannot resist posting this particular link :)

http://notinventedhe.re/on/2010-12-22

Well, I could be wrong, but it's just a sneaking feeling that vim might be faster. But I've never been able to stick w/ it long enough to know for sure....

But e.g., stuff like "." the e/E and b/B distinction, [d]f (like zap-to-char but waaay more useful) don't really have emacs equivalents.

And come on, C-f, C-b, C-n, C-p to move around -- not smart! I assume it's for "forward, backward, next, previous", but you shouldn't choose your most basic motion keys to have memorable names, you should choose them to be efficient!

In emacs, repeat is C-x z, and then keep pressing z. (C-x zzzzzzzzzzzz...)

While M-f, M-b are e and b, I don't know of an exact equivalent for E and B. But they could very easily be added.

IMHO, basic editing in Emacs has slightly higher constant factors (mostly due to typing the modifier keys), but scales much better as operations become more complex.

Cool tip about C-x z, buuut... Playing with it a little bit, it doesn't seem to fit so well with a non-modal editor, because "last command" ends up being more like "last keystroke". E.g., if I write "I like cats" and then hit "C-x z", it enters..."s". Probably a more practical emacs equivalent is to just quickly record and replay a macro.

As for adding equivalents to E and B, sure, but what keys do you bind 'em to? Either unwieldy C-c FOO combinations, or spend the rest of forever playing whack-a-mole with various modes that happen to have already defined the keys you wanted to use. While emacs is infinitely customizable, the baseline editing functionality that everything expects is important -- otherwise you're just fighting against the grain. Though the various vim emulation modes have made a heroic effort...

It would be interesting if something like that vim keystroke competition could be expanded to include emacs as well. >:)

The repeat has different granularity. I prefer Emacs's, but, matter of taste I guess.

"Super"-f/b are free on my keyboard, where "super" is the button with the Windows logo on it. I don't really miss the E/B functionality, though, and I used vim for about five years before I started using Emacs.

Ah, I was wondering how much vim experience you had. Quite a bit! Well, thanks for being an interesting data point. :)

(BTW/FWIW, I'm on mac and keep the option key as command, so no extra key lying around for me to use as super.)

I know this is a late reply, but you're very right about C-x z and vi's . having different groupings. I'm so used to defining keyboard macros for any operation I want to repeat as a whole that it didn't even occur to me.

I'm easily sucked into vi / emacs threads, and I've talked about this at length a few times. I have a bit over five year experience with each, at this point. I prefer vi's general keyboard interface design (edit vs insert mode, etc.), because it gets rid of most of the modal keys that Emacs uses, but strongly prefer Emacs's "continuous environment"/integration and general extensibility. On the balance, I prefer Emacs. (And while there are vi-emulation modes for Emacs, such as viper, few extensions provide vi-like keybindings for them.)

Vim is definitely faster at starting up ;)

For "." you could say that C+k,C+_/C+y does most of what I want done -- and arguably, the more complex cases might be amenable to using regexp-replace.

Regretfully, the only time I ever use hjkl is to play crawl :) The emacs keys are perhaps more geared towards using modifiers, with M-f/M-b + C-f/C-b serving as the closest replacements for movement, and M-z for zap-to-char.

Faster startup ain't nothing! I'm religious about making my .emacs only load modules on demand (using autoload and eval-after-load -- lisp is a great editor customization language, actually), and have managed to get emacs down to 250ms:

  gin17 ~ $ time emacs --eval '(save-buffers-kill-emacs)'
  real	0m0.256s

But that's still a lot slower than instant, which is where vim is:

  gin17 ~ $ time vim --cmd :q
  real	0m0.006s

I definitely don't feel that emacs editing is bad, and I use and appreciate one-off macros, [regexp-]-isearch-and-replace, and killing and yanking (the kill ring is awesome), but...I think the grass might be greener.

Well, after all this discussion, I'm probably morally obligated to spend more time with vim (or maybe vimpulse) so that I actually know what I'm talking about. :)

and I get the feeling that its actual editing commands just aren't that well thought out

If only it had some way you could customize it, eh? ;)

Yeah yeah yeah, emacs is infinitely customizable :) (and you can even emulate vim), but...this doesn't work out as well as you might like in practice 'cuz there tends to be a lot of friction with various modes that weren't expecting your customizations.

Plus, I'm already not sure if the time I save in emacs is worth the time I lose fiddling with it ;)

It’s a scripting language but it doesn’t even have case/switch statements. </quote>

The same could be said about Python.

Deleted comment

The quote was regarding vimscript, not Elisp.

They're included in dictionary usage. Having a separate case statement would be redundant. Lua does the same thing.

This article lead to me reading about vim's undo branches feature, something that I had really wanted for a long time but just didn't notice existed. Thanks!

http://vimdoc.sourceforge.net/htmldoc/undo.html#undo-branche...

Why I choose Emacs http://eatingair.com/post/2829859704/why-i-choose-emacs-over...

On a somewhat related note, are there any tutorials out there for a guide to emacs and org-mode for vim users?

Deleted comment

That's not why I use Vim, and that's not why most people use Vim.

I use Vim because it's an enormously powerful tool that makes me more efficient and because I enjoy using it. (I've never spent four hours attempting to debug my code only to discover that the problem was a bug in Vim. I can't say the same about Eclipse.)

Vim and Emacs are not toys. If you think they're toys you haven't invested enough time in them to understand how they work. Note that I'm not saying that a competent Vim/Emacs user might not prefer something else. I'm saying that you can't get to the point of being a competent Vim or Emacs user without understanding how enormously powerful both are.

Vim and Emacs can do just about everything your IDE can do (and, in many cases, more). The difference is that you're not starting with everything built in and crowding a complicated GUI. You're starting with something simple and powerful and (if you want) building it up with exactly the features you want.

There are many reasons people like vim and emacs, not because they want to "say they are cool and roots." They're both simple, in their own way, but extensible and powerful. And for all the different tasks that you need a text editor, it's nice to always be able to use same thing.

+ extremely lightweight in comparison.

I think the point of using Vim or Emacs is that sometimes you don't want a full IDE. Often when I'm writing code I just want my editor to be fast and not require me to take my hands of off the keyboard. Both Vim and Emacs have much better keyboard navigation and are much faster than Eclipse.

Emacs mode in Eclipse? It has almost all of the navigation keystrokes.

As far as emacs not being everywhere, I recently just learned about mg on openbsd. If I had just rtfm I would have found it years ago.

Deleted comment

> Ok, I agree, maybe for scripting and small code, but anything more complex is just for the Hype of saying I am a Emacs user and you are just a plain dumb Java developer that uses eclipse.

Sorry, no. I don't have any prejudice on whatever programming language you use, but you're making yourself look like a plain dumb person, period by saying that you can't be productive with Vim or Emacs with large pieces of code.

Here's just a few notable cases...Guido and Python with Vim and Emacs, Torvalds and Linux/Git with MicroEmacs, Stroustrup and C++ with Sam, DHH and Ruby on Rails with TextMate, Matsumoto and Ruby with Emacs, Zawinski and Mozilla with Emacs, Steele and Scheme with Emacs, and on and on.

Ridiculous.

> you can't be productive with it if you need to write more than small pieces of code.

This is possibly true in Java, but in better languages you don't need much help from your editor to be productive.

Oh please... emacs and vim are way behind even crappy IDEs let alone solid ones like Netbeans. They lack some basic features that any working programmers cannot be productive without. I'm not talking anything fancy like Intellisense but basic features like syntax highlighting, file browsing , and a decent debugger are missing. I know someone is going to say "oh but you can configure and hack around to get those features", but thing is I don't wanna have to fight with my development environment to get these basic features.

This isn't even remotely correct. Both emacs and vim have had those features out of the box for years. Decades, even.

vim comes with syntax highlighting and file browsing built-in. You just have to enable the syntax highlighting, but it's one command to put into your rc. Yes vim has some sucky defaults, but it's disingenuous to call these simple cases "hacks" or to suggest it takes fighting the software to get it working.

vim doesn't have a debugger since it's outside the scope of vim, which is just an editor. If you want an "all-in-one" philosophy, maybe emacs will treat you better.

Wovon man nicht sprechen kann, darüber muss man schweigen.

I couldn't disagree more. I had the hardest time switching over to Vim because there is such a high learning curve, but once it "clicked", I could never back. Sometimes I'll have to do some .Net work in Visual Studio and I feel like I just switched from a Ferrari to a Corolla.

Now, if you're doing work in compiled languages like Java and C#, the code-completion of Visual Studio and Eclipse is very valuable. But besides that, I'd much rather have a simple and fast editor over a bloated IDE with tons of features.

You don't use Vim 7 completion?

http://linuxhelp.blogspot.com/2006/09/visual-walk-through-of...

I'm a dyed-in-the wool emacs user (and have played with vim quite a bit) but there's really no comparison between the "completion" vim and emacs offer and that provided by IDEs like VS and Eclipse. They do quite a bit of static analysis and do context-sensitive completion which is extremely helpful when the standard library for your language has a ridiculously bloated API (like, for instance, Java and .NET).

vi emulation in visual studio - https://github.com/jaredpar/VsVim

Reply on news.ycombinator.com