Vi and Vim vs. Emacs Shootout and Deal

There's some HN discussion about the new release:

http://news.ycombinator.com/item?id=2059909 http://news.ycombinator.com/item?id=1181589

And another link I found helpful:

http://batsov.com/Emacs/2011/08/19/a-peek-at-emacs24.html

But yes, your plan is a good one. Start by running

  C-h t

to get the native tutorial, then ramp up from there. I'm afraid I don't know many good online tutorials as I work with Emacs power users, but Stack Overflow has always been quite helpful for learning Elisp.

I would suggest just getting emacs 24. If you are on OSX you can build the emacs head using homebrew. There's some cool stuff in 24 like the emacs package manager (package.el) etc.

Once you have emacs 24 ready to go, it's a good idea to take a look at the emacs starter kit: https://github.com/technomancy/emacs-starter-kit

There's also a pretty good peepcode screencast on emacs, its a bit old, but gives a good overview of a lot of the basics.

Once you feel like delving deeper, your best bet is to snoop around on emacswiki.org

Besides the inline manual that emacs has in itself. I recommend you to start using the Emacs Starter Kit [1].

Try to read the source and understand what it's doing. You will learn how to configure emacs, and the basics of elisp.

[1] https://github.com/technomancy/emacs-starter-kit

I would just get _some_ version of Emacs and spend an hour with it. The core set of commands is what you want to learn. You don't care about any of the eye candy they've added in the last 20 years. Seriously. Save the "superior LISP session auto yanking" nonsense until you're a power user.

Emacs (and most of the Emacs clones) come with a tutorial. It's pretty decent.

After a while you may find yourself feeling bad that you've not done any customization. "Argh," you say, "This is supposed to be a customizable editor. I should start customizing it so that I can realize the awesome power of this fully operational editor!" No worries. I'm guessing that most Emacs users really don't change much. For C hacking or writing I usually just tweak some settings, add a few macros and I'm good to go. Most of my customizations are turning /off/ things that other folks thought were good features. No names, now. :)

tl;dr; Don't worry about the new shiny. There's plenty to learn before you get there.

[emacs user since 1979]

I learned a lot of things using apropos-command (after I got comfortable with basic editing.) When I found myself thinking "it would be cool if emacs did X", I just tried C-h a X Ret to see if there is a function for it. Emacs also tells you to which key sequence the function is bound (if any.)

Exploring Emacs that way is like browsing Wikipedia going from article from article: you don't follow a predetermined itinerary but end up learning a lot along the way.

They've paid a lot of attention to defaults, pretty much for the exclusive benefit of newbies.

Sorry about that.

My intention was pointing out a promo for two DRM-free e-books (I own both) and the related Emacs vs. Vim vote.

Well, now I feel stupid. But still, if you sell something that needs to be shipped - show the shipping price as soon as possible.

There is a lisp written in VimL[1], so it's theoretically possible. Practical, probably not. But possible. The long-running "emacs is a great OS without a text editor" jab is partly true; Emacs is best described as a Lisp environment that happens to be built around a text editor.

[1] http://www.vim.org/scripts/script.php?script_id=1986

Not really, due to some design choices in Vim. http://upsilon.cc/~zack/blog/posts/2008/11/from_Vim_to_Emacs...

The philosophy is very different. Emacs is really a lisp repl with a good API to manage windows. So, in a way, it's not an editor. I mean, you can use it to check your e-mail, chat on IRC.. or basically anything that can be interacted through a window (I.e. mostly anything)

Also, mostly everything is a command in Emacs.. So, when you press "a" it basically translate to "call the function insert-character 'a'". So, in a way, Emacs keybinding are really just a little api over the real commands.

In vim, it's a totally different philosophy. Everything is based on making the editor as efficient as possible. Yes you can hack stuff and go on IRC with Vim but conceptually, it's not what it's been designed for and you'll likely hit lots of problems down the road and will have to use all kinds of hack.

So, is putting emacs in Vim possible? Vimscript, even thought being an abomination (my opinion), could implement elisp.. with all the necessary wrapper. So, maybe that'd be possible.. but rather useless.

Finally, my personal opinion.. with Vim, I really felt like "tweaking/hacking" it when I tried to customize it. For instance, I'd try lots of different mapping/paste things found on internet and hope it'd work. Sometime it'd fail for obscure reasons.. and you'd add another hack on top of the hack to fix it.

On the other hand, in Emacs, I feel like I'm really coding my editor as I want it. I'm not surprised by its behavior or its interface. I.e. You can bind an event to call a function when a buffer opens. If you know a little bit of lisp, you'll feel right at home. And if not, there's no better way to get started with that fabulous language.

I would contest the assertion that emacs is powerful enough to emulate vi. Every attempt I've seen so far has been a superficial effort that enables some keystrokes but doesn't really get at the heart of what makes vi(m) what it is. I was actually a full-time emacs user for several years. There was a lot I liked: lisp, programmability in general, readable-if-verbose-identifiers. But I went back to vim because it offered enough programmability (I had been using plain vi before!) to suit my needs, but it had the addictive center of the vi experience. That is:

* The action + (motion | text object) system. I haven't tried evil yet, but viper and vimpulse just don't seem to get this right. It's there but it's incomplete, which kinda kills it for an experienced user. More importantly, though, it's broken. Text objects aren't real, atomic elements at the deepest level -- they're simulated programmatically, which means the illusion breaks down if there are errors in the middle. It also means there are things which vi gets for free in all circumstances that the emulator has to laboriously simulate each time -- like atomic undo. Of course, you CAN do all the programming (hasn't happened yet) but all of that circumlocution has a cost, which is...

* Performance. I was shocked, when I tried out vimpulse on a relatively modern machine several months ago, 15 years after I last used emacs regularly, to find that emacs still feels like a movie with the framerate set too low. It's especially noticeable when, courtesy of viper and vimpulse, you can compare commands somewhat apples to apples. There's just this little delay. It might be milliseconds, but when it's something you're doing all day every day, that really starts to annoy.

So, no. I don't think emacs CAN emulate vi, if you actually consider what most vi users value in their editor. At best, it reaches the level of, say, eclipse emulating emacs movement keys. I would love an editor with vi speed and the movement model, but a sane programming environment. I'm still waiting.

(Sublime text 2 seems like it might be heading there, though for now its vi mode is not much better than vimpulse.)

Evil is the most recent 'vim-mode' for Emacs.. I'm sure there're still few bugs in it but as far as I can see, it's really good. The nice thing is how easy it is to configure/change the default behaviors and also how fast the mainteners/implementers answer your question.

Also, I think it's important to point out that these mode try to "integrate" as best as they can with Emacs. So, it's not Vim in Emacs, but more, Emacs with Vim' best features and keybinding. (Arguably the best feature of vim). For instance, evil for emacs is a little bit like clojure for Java. I.e. it's a totally different beast but doesn't force you to make dozen of wrappers.. you simply use both at the same time.

I use emacs with viper and vimpulse (http://www.emacswiki.org/emacs-es/vimpulse.el) and I'm very happy. This setup does support text objects.

I have not used evil, so I'm not sure how vimpulse compares with evil.

Evil is the most recent 'vim mode' for Emacs. I've had a couple of problems.. submitted an issue of github and it was resolved in hours (if not minutes). (For instance, :<number> was missing to go to a line.. fixed in minutes. I wanted jk to behave like <esc> in insert mode, I've been redirected to a post explaining how to do it, etc.)

The great thing about evil (and other vim-mode) is how it is easy to customize it as you wish. IMO, it's even easier to hack than with vimscript. For instance, I rarely use shift+j in normal mode and decided to use it to go go 4 lines down.. same for K and I want it to work in visual mode. Here's how I did it with evil:

  (define-key evil-normal-state-map "J" "jjjj")
  (define-key evil-normal-state-map "K" "kkkk")
  (define-key evil-visual-state-map "K" "kkkk")
  (define-key evil-visual-state-map "J" "jjjj")
  (define-key evil-normal-state-map "0" "^")

So basically, I find it pretty cool that I can customize how I want my vim-mode to behave. And obviously, from vim-mode I can call any normal elisp functions.

It's impossible to find an editor that'd fit exactly your need without you customize it because that's how we are.. everyone using Emacs or Vim use it because they want to have their own personal editor with their own function/binding.

However, Emacs with Evil was what I was seeking for a couple of years. I wish I could have made the switch sooner.

Although I use VIM pretty much exclusively and haven't really used EMACS in a while, I have been impressed with LaTeX mode in EMACS and wish that was the way things worked in VIM.

My guess is that you get some areas where it is a crazy franken-editor and some areas where it may actually be pretty cool.

I use evil-mode myself. And yes, it's definitely a crazy franken-editor, but I prefer it to dealing with vim's API. I wish that "." respected the previous visual mode, though. Makes indentation a pain.

Oh it is, my friend, it is!