1. 19
  1.  

  2. 11

    I use evil-mode in Emacs. This is almost feature-complete and supports text-objects. It also have various extensions like evil-surround and evil-numbers (for increment and decrement). I like to think of Emacs as a general-purpose development environment and evil-mode as the sensible keybinding list for editing. Since it supports all the features that the author has mentioned, I think it flies right at the face of the conclusion.

    1. 2

      Can you expand on the “general-purpose development environment” part? Specifically what IDE features you are using that VIM doesn’t have?

      1. 3

        Feature debates tend to go down the wrong path because everyone uses a different subset.

        Instead I find that the best argument for using emacs / EVIL over vim is based on how crappy vimscript is. Also, instead of thinking of emacs as another text editor, it’s probably better to think of it as a super powerful elisp repl that happens to do text editing. emacs internals are completely exposed to the user as opposed to what’s available via vimscript.

        1. 1

          Yeah, I have no intentions of starting a feature-off. I have recently started using emacs (evil-mode because muscle memory) but I still use it very much like vim, mostly because I have no exposure to the more ide like features (read none).

          1. 2

            Most of the stuff you get in an IDE you also get via extensions or standalone tool support (built-in debugger, project building, checkout / checkin, ctags / cscope support). I don’t mind keeping another terminal open for tooling stuff so that doesn’t bother me, but in my opinion the biggest advantage of IDEs is good ctags / cscope support.

            Let’s take this example:

            class A(object):
                def foo():
                    pass
            
            class B(object):
                def foo():
                    pass
            
            a = A()
            a.foo()
            

            ctags has poor OOP hierarchy support and doesn’t know where a.foo() points to. It will bring up a list of all foo() definitions with the most likely one first. This is ok in small projects, but a pain point in larger codebases.

        2. 1

          I love the buffer management capabilities of Emacs. At any given point, I have 40+ buffers and with ido, buffer-name completion is brilliant. (perspective-mode is something you should not miss too)

          The M-x shell is good enough for 99% of the things I need to do, but M-x term is always there (which can run a full vim inside it if you wanted) for more curses-oriented apps.

          The self-documenting and completely customizable nature of the editor and most packages is also a very important feature for me.

          I don’t really need auto-completion so much (M-/ in emacs | C-n C-p in evil) is often enough for me). But I do use auto-complete-mode when I know long words are going to repeat often enough.

          With evil-mode find and replace shows a hint of what it is going to replace. Beat that, other editors.

          Also, I use ace-jump-mode (which I think is inspired from a similarly named vim plugin) for lightning fast navigation. magit satisfies all my git needs.

          I have been using dired for ages and I still think it is one of the best file-managers out there.

          All said and done, given the number of languages I fiddle with, I don’t care about context-sensitive completion. I would need 10 different IDEs to do that efficiently. I am happy with a fast, dumb, text-based auto-complete.

      2. 3

        The article is spot on. What seems to have happened with text editors in the past few years is that we’ve traded off a lot of power in favor of easier learning curves and UI. The challenge for the next big deal text editor is to achieve both of those two things without trading off too much power.