4 ms·
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
by vsbuffalo 12y ago
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 12y agoCode (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 12y agoWell, 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-returning-to-emacs 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 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-fuzzy-code-completion http://emacs.stackexchange.com/questions/2671/how-can-i-get-...
- chongli 12y agoNeovim 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 12y agoUh, Emacs has asynchronous IO, and it works fine. http://www.gnu.org/software/emacs/manual/html_node/elisp/Asynchronous-Processes.html http://www.gnu.org/software/emacs/manual/html_node/elisp/Asy...
- chongli 12y agoIt 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 12y agoIt'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 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 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 http://tuhdo.github.io/static/c-ide/gdb-many-windows.gif. Another GDB screenshot: https://flic.kr/p/6FW7Q7 https://flic.kr/p/6FW7Q7. And Emacs officially supports asynchronous IO, while in Vim it's a hack from Vim Script.
- tuhdo 12y agoWhat's wrong with Company: http://company-mode.github.io/ 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?