1. 15
  1.  

  2. 10

    If the basic critique is, “I want Emacs/Vim/Atom/… to work like Sublime”, then yes, Sublime will do a better job. Maybe if you try real hard and use the best elisp-fu you’ve got, you could get somewhere close, but honestly, I think that’s just as much the telos of Emacs (specifically) as an NES Emulator.

    Nevertheless, I’ll attempt a defence of Emacs:

    Another problem with this pile-of-hacks design is that nothing was consistent or discoverable.

    While hacks usually have a negative connotation, as in not well designed, I think of Emacs being more like a miracle hack (as in the fact that Emacs is usable contradicts all known laws of computer science). It has some good fundamental abstractions that if employed will reward the user. Take for instance discoverability. This is true, if you haven’t engaged with the Emacs help system. You can easily see what key is bound to what command, open the command documentation, find out about options through it’s hypertext system, etc. Enter a prefix key (such as C-x, M-s, …) and then C-h (for help) to generate a listing of command with (for the most part) telling names.

    I will admit that consistency is a different issue. AucTeX, markdown-mode and Org all use different key bindings to generate markup. But on the flip side, all modes deriving from special-mode have a lot of keys and customisation in common. So this is a active design issue, not a problem of the “pile-of-hacks design”. Other examples might be that by defining the forward-sexp-function or turning on subword-mode, basic text-concepts can be modified, while keeping the keybindings for quite a few commands (since for example kill-sexp is based on forward-sexp that in turn uses the value of forward-sexp-function).

    Also, regarding “pile-of-hacks design” – I have the feeling that the more transparent a system is, the more one is inclined to critique it. Think of a friend trying to explain a philosophical idea of his, as compared to him trying to explain an “established” concept. Same with people disregarding Linux/Free Software, because it wasn’t developed by a serious company. Just by obfuscating the source, the idea might seem more credible, without changing the idea. So too, will Emacs “open door” policy let you see some of the rough edges and elegant “hacks”. From my knowledge of Sublime, you are shielded from the internals, invited rather to enjoy the possible illusion of order and cleanness – essentially promoting a “consumer” rather than a “user” attitude towards ones own tools.

    I tried to do this in Emacs once, and had to spend a ton of Googling and investigating M-x listings:

    • Look up how to search in project without regex (I’ve never figured out a way to do this)
    • Look up the shortcut for pasting into the minibuffer (I use Evil so I can’t use p like usual).
    • Hope that the command is Helm-based so I can edit my query, otherwise re-type everything to narrow it down.
    • Look up how to replace in project without regex, oops it’s an entirely different command from searching.
    • Re-enter everything into the new command and run it.

    My suggestion, use find-grep and add the -F flag (for “fixed strings”). A buffer should pop up with all the matches, you can navigate these by jumping to the exact matches with C-c <right>/<left>. Pasting should just be C-y, unless Evil/Spacem. unbinds this (which is why knowing the platform your higher-order-platform is based on is helpful – just like with grep earlier).

    Replacing could ether be done with a conditional macro (see kbd-macro-query) or with an extension like wgrep.

    Also, re-entering/editing commands doesn’t require Helm. Usually M-n/M-p do what you mean.

    The main point is again, know the mindset of the tool you’re using. I tried VSCode a while back and disturbed that I couldn’t use it like Emacs – it then occurred to me that this is the same complaint I hear from Emacs-newcomers, and I had to laugh.

    There’s three main ways for working with files in Emacs: buffers, files and windows.

    Uhh, not quite. It’s more like you have buffers that might refer to files that might be displayed in windows. It’s all the same thing.

    I tried using buffers but the problem is that buffer switching is slow and difficult.

    If you enter anything, anywhere, you’re using a buffer. Other than that, C-x b for a specific switch, C-x C-b for a list and C-x <right>/<left> make buffer actually quite comfortable, imo. Especially with an enhanced completing-read frontend such as Ivy or Helm that might even integrate “virtual buffers” (eg. recently closed buffers) with flexible regular expressions, and quick filtering.

    Navigating using normal find-file and helm mechanics has a similar problem: switching is just slow. It takes a lot of key strokes, and those strokes sometimes involve waiting for a list to appear that you can read.

    This has been an annoyance for me too, but recently I’ve started using counsel-find-jump to select any file below the current file system hierarchy. But generally this can be annoying.

    With Sublime Text I use tabs, which are amazing. I can switch quickly and directly between files with cmd+1 to cmd+9, see all the files I’m working with at a glance, and navigate with the mouse if I want to.

    Emacs is actually mouse friendly – maybe even more so since it can distinct between a quite wide range of different mouse events. But if the main point is that you can quickly switch between a set number of buffers, this is just an example of a “consumer attitude” I mentioned before (which surprises me since this guy has participated quite a lot to Spacemacs). There are many ways you could go about this issue in fact. Write a elisp function that uses something like (nth n (buffer-list)), use registers/bookmarks, … If tabs are “amazing”, then this really only speaks of a rather inefficient usage of the default facilities that Emacs has to offer.

    Yes, Emacs has plugins to add tabs but they are hacks. They’re ugly, slow, break when used with other plugins, don’t have good keyboard shortcuts, and display tons of useless buffers I don’t care about.

    Here just the bold part (my emphasis): You’re ideal keybindings are always two steps away:

    1. a good keybinding
    2. a define key

    you might guess that the real art is in the first step.

    They look super efficient since they’re furiously typing things or navigating directories, but often the file they are opening is one that they looked at just a minute ago and would have taken me a single keystroke to switch to.

    I would want to claim that most text editing doesn’t consist of “switching between directories and files”. Then again, narrowing by typing the name really doesn’t that that much time compared to a “single keystroke” (that’s still limited to only 8 buffers and requires a possibly diagonal keystroke from control to 7 for example). Especially with extensions/external tools like counsel-rg, jumping anywhere in a project is really easy.


    Anyway, this had gone on for too long – it’s more of a blog post in it’s own right actually. I didn’t even realize how long this became, since I didn’t write in all in one go, but to not just appear as a Emacs maniac, I want to clarify that my main issue is the stance towards software that the author seems to have, especially towards free software as a practical software philosophy, that disturbed me. But in the end, my main point was said in the first sentence: Don’t expect the best when you force one paradigms over another tool.

    1. 6

      I’m a power Emacs user (no Spacemacs for me like the author though), and I found myself agreeing with many of his points, but most of all two that are there, but not explicitly spelled out: (1) defaults matter, (2) optimize the common case.

      Regarding defaults, the best Emacs packages I’ve installed in the past few years is Ivy and its Counsel companions. The reason why I love these packages so is that I have just two configurations for them; otherwise, the out-of-the-box experience is exactly what I want. I’ve put a few of my favorite commands (e.g., counsel-rg, counsel-git, counsel-recentf, swiper, etc.) on easy-to-access shortcuts and that’s the extent of my effort configuring Ivy. In contrast, I tried Helm a few years ago (back when I used Ido), but I quickly gave up because, like the author, I found myself putting in too much effort to get the behaviour that I wanted, and the result was just crappy.

      Ivy and Counsel are also great examples of optimizing the common case. When I use counsel-rg, it’s smart enough to find the root of my Git project and start the search from there. I didn’t need to configure this and it’s exactly what I want.

      I agree with your point that you need to use an editor the way it’s meant to be used; but maybe Emacs needs to evolve a bit. I was encouraged by the addition of line-number-mode in Emacs 26: many users requested that feature, some of the old hands pushed back, but in the end it was added to provide a faster and more solid experience for all. There’s currently discussion of a built-in indentation highlighting feature for Emacs 27. I find that this is the kind of work that Emacs needs to do to remain relevant: listen to users, provide the common functionality out of the box, and make the defaults so good that most people don’t need to modify them.

      1. 1

        I agree with your point that you need to use an editor the way it’s meant to be used; but maybe Emacs needs to evolve a bit.

        I don’t see why there should be a contradiction between these two goals. Using Emacs as Emacs is exactly improving on it. But yes, I too think that the defaults are suboptimal, and should be reconsidered – thought I don’t think that this means that the users shouldn’t be invited to modify them.

      2. 4

        Don’t expect the best when you force one paradigms over another tool.

        I think the article is a response to the countless people who think that editors other than Vim and Emacs aren’t as good or efficient, when clearly, Sublime Text is better for the overwhelming majority of people – even including power users. I have used and loved Emacs extensively, and it’s a wonderful Lisp machine, but not a very polished editor. It’s hard to describe; everything just feels a bit clunky.

        There are plenty of people who give unfair criticism to Emacs, and I don’t like that, but this article is fair.

        1. 1

          That argument would make sense, and I would agree, but it was sections like

          They look super efficient since they’re furiously typing things or navigating directories, but often the file they are opening is one that they looked at just a minute ago and would have taken me a single keystroke to switch to.

          that (in my eyes) try to imply that Emacs/Vim/etc. are all just editors with a lot of typing overhead, where I had to disagree.

          1. 1

            Sure, I agree that’s more of a matter of preference. But the fact that Emacs doesn’t support tabs (in any non-clunky, non-hacky way) is a good example of how limited it is by its historical baggage.

            1. 1

              Yeah, there’s a lot of historical baggage, where tabs are the least-bad example. What I think is more annoying is that the point always has to be visible in the current buffer. There’s something about the cursor and the point being connected on older terminal frontends, maybe even with the current curses interface. Or that C-i/C-m/… can’t be rebound without changing tab, enter, etc. does.

              The only qualification I would like to add to that would be to keep the architecture/concept of Emacs (as a lisp interpreter with text-editing side effects) mentally distinct from it’s particular implementations – with all it’s achievements and faults on both sides.

      3. 5

        I use vim with mouse mode set to on. It works perfectly, scrolling and all.

        Whoever doesn’t use this mode is fooling themselves IMO. Just as the author explains, and other UX experts, the mouse has a time and place, and when it comes to selecting, or casual text navigation, nothing beats it.

        Combine this with markers, Ctrl-P, git grep or ripgrep, vim-sneak, and you’re flying. I’m at the point now where I haven’t added anything to my vimrc in ~2 years (vim users for almost 10 years now), and it’s under 20 lines. Eventually the end game is to recreate this as an all-in-one from-the-ground-up editor built for me and me alone.

        1. 2

          agreed. i don’t doubt that sublime does some things better than vim, or that it fits the author’s workflow better, but vim works way better with the mouse than he suggests.

        2. 4

          Great post. Sublime Text is really the best cross-platform editor, hands down. Clean design, fast, feels lightweight…

          nearly everything I contributed was fixing a bug or annoyance I encountered while trying to get something done, often writing the elisp to fix an earlier problem.

          Yes, this is the problem with Emacs… it’s too fun to configure the editor that you don’t do any actual work.