[vsbuffalo]

I hate the best editor debate because I think it's distracting from what's more important — what both editors can learn from each other and what both need to do to improve. I used Emacs for years, switched to Vim because of RSI, then recently switched back to emacs+evil. Frankly, for what I do most (R, R+knitr, C++ with clang autocomplete), no single editor is great. First, there's too little ability to switch between modes within a single buffer in both Vim and Emacs. The feature's entirely lacking in Vim AFAIK, and poly-mode in R uses a high level hack that (1) doesn't play well with other modes (including evil) and (2) has so thoroughly destroyed my documents in the past I refuse to use it now (mostly because it uses many buffers behind the scenes, which destroys undo history).

In general, if you want flawless R support in certain blocks of text (as in a .Rnw file) in between LaTeX blocks that are fully connected to AucTeX, well... you're out of luck. And Vim... Vim-R-Plugin is useful, but it's sort of a painful hack to use tmux just to get R and Vim to talk (and I'm saying this even though I love Tmux).

Vim has YouCompleteMe, which is smooth as silk compared to Emac's options (which are painful and poorly integrated, especially with clang). But some lower-level issue in Vim causes this constant error message in Vim whenever YouCompleteMe uses clang — bloody annoying. So overall, both editors have huge issues that would require serious overhauls or tedious bug fixing in various modes. Sure, Emacs does AucTeX better, but until it does everything better (or Vim does everything better) it's a flawed editor. Both are flawed editors. But sadly everyone thinks the best course of action is to start fresh — which usually creates a feature-poor flawed editor on a new shiny foundation, that fails to attract developers because it's feature poor. (apologies for ranting -- jetlag).

[RBerenguel]

Code (live code) + LaTeX can be done with org-babel (kind of,) and I use mmm-mode (sorry, not on my computer now and don't remember the precise name, but it's on Melpa) and for multiple major modes in different blocks, works nicely (but don't know a way to keep the defined modes per section across sessions/file closes)

[melling]

Well, the "best editor debates" do keep people from being insular. :-)

Are the vi keybindings really better for your RSI? I've heard different stories. For example,

http://changelog.complete.org/archives/661-so-long-vim-im-re...

There's a new ergoemacs mode that I haven't tried yet: http://ergoemacs.org

Personally, I spend more time using IntelliJ, Xcode, and Sublime these days, but recently I started using Emacs again for a bunch of .org stuff.

By the way, there's an Emacs StackExchange which will hopefully make emacs more accessible.

http://emacs.stackexchange.com/questions/2671/how-can-i-get-...

[chongli]

Neovim has a good chance to become the best editor. They are taking a really hard stance against all the cruft in Vim and have some really great features already implemented. I'm especially excited about their goal of reimplementing all IO with libuv. The lack of proper asynchronous IO has been a sore point in vim and emacs for a long, long time.

[catern]

Uh, Emacs has asynchronous IO, and it works fine. http://www.gnu.org/software/emacs/manual/html_node/elisp/Asy...

[pmoriarty]

Perry Metzger talks a bit about the problems of emacs blocking starting at the 34'39" mark in his "The Editor of a Lifetime" talk[1] for the NYC Emacs Meetup. Not that his points are new, but this is just one of the first things that sprang to mind when I heard your "it works fine" claim. Here are some excerpts:

  "Threading.  This has been an irritant for me for years.  Emacs
  blocks all windows when you're doing computation in any window.
  It's an operating system, but not enough of an operating system.
  I myself will run three instances of Emacs to get around this.
  I'm slurping in my email and I can't do something at the same time
  because it's off in space slurping in my email.  It's going off and
  doing some extended computation and I can't go in another window and
  do anything else at the same time. ... If it's doing extended
  computation and a lot of file IO and talking to the network, it
  blocks you.  There's not more than one thread there."

There's also this[2] discussion of lack of threading in Emacs on the Emacs Wiki.

[1] - https://www.youtube.com/watch?v=VADudzQGvU8

[2] - http://www.emacswiki.org/emacs/NoThreading

[chongli]

It has support for AIO, as had vim for quite a while, but it's not pervasive in the standard library and the ecosystem. Both editors have way too many plugins that block the UI needlessly while you're typing (autocompletion, syntax checking etc).

[tuhdo]

It's quite more popular than you think. `M-x term` is an example. It's a full-blown terminal emulator in Emacs that runs entirely in another process. Here is another example of async grep/ack/ag: http://tuhdo.github.io/helm-projectile.html#sec-9 . As you can see, Emacs gets line by line results from grep/ack/ag without blocking and gives you new results and you type.

Or Emacs's fantastic support for communicating with REPLs in many interpreted languages.

You can execute any shell command asynchronously while doing other things inside Emacs. You can even compile with beautiful output, in terminal: http://tuhdo.github.io/static/c-ide/compilation-compile.gif

Or built-in GDB integration, also asynchronous: http://tuhdo.github.io/static/c-ide/gdb-many-windows.gif.

Another GDB screenshot: https://flic.kr/p/6FW7Q7.

And Emacs officially supports asynchronous IO, while in Vim it's a hack from Vim Script.

[tuhdo]

What's wrong with Company: http://company-mode.github.io/? It can give me a large amount of completion candidates without any issue. It's also smooth. Maybe you are using auto-complete?