Hacker News Reader

Comment by sph | Hacker News Reader

Evil mode is better than VIM itself and a good editor for the Emacs operating system which previously lacked one.

Many people constantly recommending Evil mode don't seem to get why some use Vim.

No, Evil mode is not better than Vim itself. For one it's slower, defining keybindings is much more verbose, everything outside the actual text file has completely different controls, and I lose most of the seamless interoperability with other terminal tools. And it runs within an environment that tries to be literally every text-related tool by itself, making it overly complicated in many aspects.

> everything outside the actual text file has completely different controls

Not sure what you mean by this

> lose most of the seamless interoperability with other terminal tools

It's not like VIM is more or less interoperable than Emacs is with other shell tools. They live in their own space, you don't (often) pipe stuff in or out of it.

Though there's not much to read into my comment, it was an attempt of being witty, but evil mode is the best VIM implementation found in any editor and just for the fact that Elisp >> Vimscript, makes evil mode a better environment than VIM itself.

> They live in their own space, you don't (often) pipe stuff in or out of it.

Well that's not true at least for vim.

: read !FOO

will run the FOO command and read the results back into the current buffer. I usually search my codebase by reading the results of a grep into a temporary buffer and 'gf'ing to the appropriate file

There isn’t much Vim can do which ed cannot, though.

Except for some extra trivialities, like everything that isn't an ex command (and some that are).

C-u M-! does the exact same thing in Emacs.

But that goes back to the original point they made, everything outside of the actual text editing and you're in EMACS land with all of it's controls. Even with something as complete as spacemacs, the default landing page when you open it has different key bindings.

As a Vim user who uses Emacs for note taking, I can guarantee Evil mode does far better at emulating Vim than you give credit for. In fact, the example you provided works just as well with Evil. The only built-in editing command which I notice missing from Vim is reliable undo/redo, which is sadly a fundamental Emacs limitation and a deal breaker. Apart from that, it's remarkably well-made.

Emacs 28 is finally adding modern undo-redo: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=2645ae...

Recent versions of evil have the option of choosing undo backend, and I have found the new buildin one impeccable thus far.

My understanding is that it's still not as good as Vim's builtin undo though. Vim has a persistent undo tree that consistently works and doesn't confuse users. AFAIK the best attempt at it in Emacs is the undotree package, but it unfortunately has a reputation of being unreliable.

I've made no statement about emacs or evil mode. I was just correcting the user I was responding to about vim having interoperability with the rest of unix

> I usually search my codebase by reading the results of a grep into a temporary buffer and 'gf'ing to the appropriate file

I used to do that too, I now use the Ack plugin which is almost instantaneous on a codebase that grep used to take 2s-3s long to search. The speed isn't what matters though, it's the fact that Ack only searches source code, not all files so my results is less polluted with irrelevant matches.

my grep of choice is `ag "searchterm" -G .py` or the like. I don't notice any delay, and I'm specifying the file extension

> They live in their own space, you don't (often) pipe stuff in or out of it.

...huh? I pipe things into vim absolutely all the time.

I don’t mean to be rude but this is exactly the sort of thing OP meant by “people recommending evil don’t understand why people like vi(m)”.

    whatever_command | vim -

and edit the results as needed.

and in emacs you can just redirect the command output to a buffer. or honestly, 99% of the time, I don't even bother redirecting and muck with the output directly in the eshell buffer.

No reason to be rude, I have used VIM for 15 years, I know how it works.

Yes you can pipe stuff in and out, you can do in Emacs as well.

My point being that VIM isn't better than Emacs on this aspect, and they're not like other shell tools where COMMON usage is by piping stuff in and out; they're not like cat, more, wc. They live in their own space.

> No, Evil mode is not better than Vim itself

Emacs provides a convincing Vim layer on top of a hackable LISP runtime. While there's not much point in trying to decide which one is "better," it's not an entirely unfounded point.

> For one it's slower

Could you be more specific? At least for me, there's no noticeable lag when using Evil mode.

> defining keybindings is much more verbose

This is why some use Vim? I don't see how this:

    (define-key evil-normal-state-map (kbd "w") 'some-function)

is any worse than this:

    nnoremap w :<C-u>call some-function()<CR>

I for one could care less about how keybindings are set, as it's just something that I write once in a config file and forget about.

> everything outside the actual text file has completely different controls

It's because Emacs is more of a runtime for elisp applications. As such, it makes sense to have different behaviors for each key depending on context. FWIW evil-collection does a pretty good job of making keybindings feel consistent outside of ordinary text buffers, so you won't have to fall back to Emacs keybindings these days.

> I lose most of the seamless interoperability with other terminal tools

This is plainly false. Shell interoperability in evil works exactly the same as in Vim.

> overly complicated in many aspects

This doesn't mean much without specifics. Implementation complexity isn't inherently a bad thing as long as it provides value.

Besides, Emacs is a just a LISP interpreter at its core. If anything, it's easy for programmers to grasp and hack on.

> Could you be more specific? At least for me, there's no noticeable lag when using Evil mode.

Long-time Vim user here. I tried switching to Doom Emacs for a few months. I really, really wanted to like it. As a nerd, the infinite customizability is like catnip to me. It has a really mature plugin ecosystem and you can have a really comfy computing setup with magit, org mode, dired, mu4e, etc...

But Emacs is intrinsically slow as molasses. The nail in the coffin for me was the scrolling performance. And I don't mean line-by-line. Even going half a page, or a full page at a time, pegs a CPU core and there is noticeable latency. The Doom Emacs documentation straight up admits it [0]. They recommend crazy things like turning off line numbers. Even with newfangled native Elisp compiler, it doesn't come even close to vim on alacritty.

[0] https://github.com/hlissner/doom-emacs/blob/develop/docs/faq...

I've been pretty happy with Emacs 27. I haven't noticed significant slowness with that version.

As an actual user of both editors, I have a hard time believing that scrolling performance between the two is different in a way that's recognizable. For both, scrolling is instantaneous unless

1. you spam the scroll key

2. you're viewing a exceptionally large buffer

3. syntax highlighting happens to perform badly on the buffer

4. some plugin is blocking the editor

For Vim, the forth situation has vastly improved with async APIs pioneered by Neovim, but it still can happen nonetheless.

As for the advice about turning off line numbers, that's just a micro-optimization. I've seen similar advice with Vim too. set nonumber nocursorline etc etc... I don't follow any of those overzealous optimization advice either on Vim or Emacs, and scrolling performance is just fine most of the time. Though for Vim, "set lazyredraw" did make a big difference in terms of scrolling performance, but that piece of advice isn't the sort that hampers usability so I don't think it really counts as an overzealous micro-optimization.

But back to Emacs, my view is that general editing performance is just fine. When you think about it, if general editing performance were noticeably horrid, that would be a deal breaker for pretty much everyone. It's mostly blocking operations that's causing problems, but that's a slightly different situation from Emacs being sluggish in general. Vim used to have this problem too up until a few years ago, but it ceased to be a major source of pain after plugins adopted async APIs. I just wish Emacs would follow suite.

On a beefy (iMac Pro) macOS workstation Emacs 27.2 is often slow at scrolling, which is also admitted in various places -- it has to do with the more pixels, apparently. Regardless of the fact that this station can also play various games at 5K resolution fairly decently...

There are zero excuses for a widely used editor program to lag that badly in 2021, on very strong hardware nonetheless.

One "hack" I found is to have your font not contain emojis. That was literally the only thing that actually helped.

And Emacs itself isn't at fault that LSP does its thing in a synchronous manner in the same main UI thread and makes Emacs super slow. I know that. But I also know that NeoVIM does the same thing asynchronously and doesn't stutter.

Sadly I'll be done with Emacs soon. I like it quite a lot but I'm not seeing any will to make it adequately fast or, at the very least, make it so its main UI thread can't be blocked.

This sends a message to me that the maintainers are using Emacs in a specific way and don't care about how others are using it. Which means that it's time to part ways.

Doom Emacs isn't Emacs. My handmade init.el was much lighter than Doom Emacs or Spacemacs ever where. Not really fair comparing a full blown setup with plugin with a barebones VIM one.

> But Emacs is intrinsically slow as molasses. The nail in the coffin for me was the scrolling performance.

Just to play devils advocate (in reality I'm a die-hard-never-use-anything-else vim user, and have been since 1996-ish), I did once manage to set up vim with so many highlighting and display options that I made my i7 crawl whenever I tried to scroll.

(The main thing that pegged the core to 100% was ':set cul' with ':set number' and various different syntax highlighting for numbers, highlighted numbers, highlighted line, syntax-highlighting within a highlighted-line, etc).

So, yeah, vim can be slow too if you nerdgasm all over the config :-)

This needs to be brought up more. The "emacs + evil" crowd tends to see vim as a set of ergonomic keybindings, but it's so much more. It's the "seamless interoperability with other terminal tools" alongside the keybindings and text-editing grammar that makes vim so powerful.

Reply on news.ycombinator.com