1. 9

  2. 1

    I’d like to elaborate with my perspective:

    I pair program with others at work. I’m the only one out of the team that lives on the command line, and have been using Vim for well over a decade (and now also use Emacs with Evil); the other programmers (sans one, who also uses Vim) use whatever editor the others seem to recommend. Most recently, that editor was PHPStorm.

    I immediately reject PHPStorm because it is non-free/libre. But watching them use it is interesting. In particular, there is one programmer that really understands its features and refactoring tools—he doesn’t often use them, but when he does, I’m quite impressed. There are some features that I found would be convenient (and there are some that I did adopt in Vim/Emacs where packages were available).

    When we were researching this programmer before his interview a couple years back, we say a post on one of his social media accounts that expressed very strong distaste for Vim and Emacs users, and said that he likes editors that can “write the code for him”. And there, I think, is where people miss the point.

    Yes, these features are very convenient—when they can be used; they are rigid, and usually (as @steveshogren stated) cannot be part of a large composition. They also often require a clumsy GUI interface, which isn’t very (or at all) scriptable. So your editor might be able to write code for you—a small percentage of that time. When you get to use those features, it feels pretty good; but most of the time, you’re typing. Maybe using some auto-completion or auto-formatting.

    From the reverse perspective, the others are impressed by the efficiency with which I edit any text—it might be code, it might not. It’s easy to write macros around Vim commands, and trivial to do so: I’ve taken over the keyboard a few times just to open the file in vim and largely automate a task. But perhaps one of the most notable things I’ve seen was that, when editing files that aren’t part of a project that’s registered with their IDE, or non-source files, they often use other programs. And even if they did use PHPStorm, it doesn’t recognize the file format, so many of their benefits disappear.

    But Vim and Emacs aren’t the only useful tools—I also make aggressive use of standard GNU tools like grep, awk, sed, cut, sort, uniq, shell one-liners and scripts, etc; those are written to be components in a pipeline, and are fundamentally composable; they work on any file, source or not. This allows for far more than text edition: you can do data processing/analysis, reporting, scripting, etc. Between the command line and my editors, I don’t need any other programs to accomplish most sophisticated tasks that others would need wholly separate programs to do. And between editor macros/scripts, piping to external programs, and shell scripts / pipelines, I can reproduce the important part of those refactoring tools to the extend that I need.

    tl;dr: This falls under the same philosophy as that of Unix: small programs (or Vim commands ;)) that do one thing and do it well, use the universal interface (text), and that work as part of a pipeline. Editors that try to think for you lose out when they haven’t thought of what it is you’re trying to do—and that’s constraining, and a hacker’s antithesis.