Why Atom Can’t Replace Vim – Learning the lesson of vi

https://medium.com/programming-ideas-tutorial-and-experience/433852f4b4d1

by jpace121 • 12 years ago

475 199 12 years ago

Monkeyget• 12 years ago

As mentioned in the article Emacs creation of arbitrary new functions and Vi creation of new shortcuts are both application of the same basic principle : composability. All you need is :

- primitives

- a way to combine primitives

Combining instructions together (and giving it a name) is just a function. This is nothing extraordinary for us programmers. However exposing that ability to users of a program for extensibility is rarely done, Yet it yields immense power for little complexity from the user comprehension standpoint.

Jare• 12 years ago

One note on this: I interpret composability as the ability to combine a variable number of primitives of the same nature, like piped shell commands, or chaining function calls. vi is more about writing phrases with a fixed structure of (optional) pieces, like verb, subject, etc in natural language.

reuven• 12 years ago

Maybe it's just me, but as an Emacs user since 1988, I've often found that the commands there were composable (to use the author's term), but in a different ways. I can kill to the end of a line (C-k), sentence (M-k), or sexp (C-M-k). And if I want to do it more than one time, I use the prefix argument.

I realize that Emacs and vi are different in many ways. And despite my love for Emacs, it's obviously not everyone's cup of tea. But if the argument here is that vi's keystrokes are such that learning one lets you learn many others, I think that the default keybindings in Emacs actually do a pretty good job on this front, once you get over the (admittedly very high) learning curve.

agumonkey7• 12 years ago

That's not 'real' composability. In Emacs, each keybindings (C-k M-k C-M-k) will run a different elisp function. They just decorated a single key with control ones.

In vi 'd' is one operation that takes a 'region' (line, word, char,...). Whatever the region, 'd' will always be a single piece of code.

The irony is that lisp being heavily function based, often orients toward composability in code, but that didn't translate into emacs keybindings at the time.

lispm8• 12 years ago

Emacs.

c-w will kill the active region.

swah• 12 years ago

Mine is the pain of loving emacs and not using because of wrist pain.

lispm8• 12 years ago

Emacs and Atom don’t have commands for deleting to the end of a file or a paragraph — even when they have commands to move to those places.

Emacs uses regions for that. I mark the position, move in any way I want, kill-region c-w.

yxhuvud• 12 years ago

Emacs also have M-h to mark the current paragraph, so M-h C-w will cut the current paragraph.

FatalBaboon• 12 years ago

i simply bound flush-lines for that

_pfxa• 12 years ago

You need not to defend Emacs (saying this per your attitude on the thread). Your argument does not defeat the argument about the lack of proper command-and-movement composition. This neither diminishes nor augments the value of your favourite editor, so no need for religiousness here.

edit: grammar.

lispm8• 12 years ago

Who are you? The spanish inquisition?

The article claimed: 'Emacs and Atom don’t have commands for deleting to the end of a file or a paragraph — even when they have commands to move to those places. But in Vim, if you can move to a location, you can delete to that location.'

I delete to the end of the file all the time in GNU Emacs. mark, move, delete. It's just a different model.

Your argument does not defeat the argument about the lack of proper command-and-movement composition.

It's not a 'lack'. Like an airplane does not lack a proper steering wheel.

This neither diminishes nor augments the value of your favourite editor, so no need for religiousness here.

GNU Emacs is not my favorite editor.

Sanddancer2• 12 years ago

Vim has regions that can be used with the other movement commands -- paragraphs, sections, words, etc, so you can get the best of both worlds.

norswap• 12 years ago

Interestingly, I think you could have the same thing than in vi in Emacs, nothing prevents it. But of course, it isn't the default, nor the way people are used to.

The post also fails the mention the concept of region in Emacs: you select a region than perform one (or multiple) commands on it, instead of encoding the region in the command like in vi.

All around, Emacs is harder on the fingers (more keypresses for the same functionality), but that's the price to pay if you don't want a separate edit and command modes; which personally I find very awkward (but perhaps it's a question of habit).

calibwam2• 12 years ago

The different modes (actually 3 in vi, and 6 in vim) recognise that you need different functionality when doing different things. If you are just writing, you don't need to have edit functionality, if you are reading you need advanced movement, and you don't need all of this other stuff when you are entering a complex command.

It is a completely different way of working, but when you realise that you spend most of your time coding not writing, you can see that spending a lot of time in normal mode, with your keys now doing useful stuff, can save a lot of keypresses.

Of course, I'm not saying that vi is perfect, and if emacs works for you, then there's really no reason to switch, unless you want to try it out for funs.

lispm8• 12 years ago

you need different functionality when doing different things.

I don't buy that. When I'm using an editor writing, moving and reading is totally mixed.

ibrahima3• 12 years ago

So in some sense there are two major features of vim, one being the composable commands, and the other being the modal editing. They seem to not necessarily be related, for example there's this thing called 'god-mode'[1] for emacs which is kind of like vim's normal mode, and control becomes implicit. I haven't gotten a chance to really adapt to using it but it seems like it could bring a lot of the benefit of vim's shorter syntax to emacs users without requiring us to change our muscle memory with regards to the key sequences.

[1] http://chrisdone.com/posts/god-mode

ch_123• 12 years ago

The post also fails the mention the concept of region in Emacs: you select a region than perform one (or multiple) commands on it, instead of encoding the region in the command like in vi.

Would the visual mode selected areas in vim be equivalent to this?

mkozlows3• 12 years ago

The region thing (along with vim modes) is probably one of the biggest pieces of pushback I've gotten from the piece, and I think it certainly has some merit to it. If you can use movement commands to define a region, and then act on that region, isn't that the same as vim's composability in effect?

I think the best answer is "sorta, but not really."

The biggest reason why is that Emacs commands don't all work on a region by default. Yes, there's C-w to kill-region, but there's still C-k to kill-line and other special-purpose commands out there. In Vim, there aren't four special-purpose delete commands and then a general-purpose one, they all work the same way. This feels like a qualitative difference to me -- both in theory, and in practice.

When I used Emacs for many years, I definitely did use the region commands, but only when the special purpose ones wouldn't work reasonably (like deleting large chunks of code). If I just wanted to delete (for instance) the stuff inside an HTML tag, I wouldn't try to mark off a region and then delete it, I'd just delete by word/character until it was gone. In Vim, I'd "dt>" automatically, because that just makes a lot more sense than repeatedly typing "dw".

And ironically, Emacs has a command (M-z is the mapping for kill-to-character) that would do exactly the same as that Vim command. But in fourteen years of Emacsing, I never even looked for it, because Emacs doesn't steer you that way. Vim makes you always think about what object you're applying your command to, and because you always have to make a choice, you look for good choices; Emacs generally defaults you to one of a few often-decent choices, and you don't get into general-purpose mode unless the built-ins are unworkable.

MichaelGG2• 12 years ago

While the elegant design of Emacs appeals to me, I found vim more enjoyable to get into. I'm not a strong vim user at all, and I use it mainly via ViEmu inside Visual Studio.

Having really powerful text-editing commands is just fantastic. I don't need an extensible shell that can work as a browser or email client. I need great text editing added to my IDE.

Also, a plug for the fantastic VIM Adventures, which can ease the process of becoming proficient inside vim: http://vim-adventures.com/

anonymoushn• 12 years ago

VIM Adventures looks great! I'd love to buy it, but the author is only willing to rent it.

MichaelGG2• 12 years ago

6 months at $25? Personally I feel I've gotten far more value out of it than that.

NAFV_P3• 12 years ago

If you think Emacs is heard to grasp, try out TECO [0], very popular on DEC-PDP's.

[0] http://almy.us/teco.html

recraft• 12 years ago

Emacs was originally written as a series of TECO macros.

kps4• 12 years ago

Emacs is nothing like TECO, though.

In some ways, vi could be considered an evolution of TECO (though I've seen no evidence that there was direct influence). They both use the same core syntax of a numeric count followed by a letter command optionally followed by an ESC-terminated argument. For example, «itextESC» is the same operation in both. (That vi calls it entering a mode rather than supplying an argument is, IMO, an impediment to understanding its compositional nature.)

lispm8• 12 years ago

If you think Emacs is hard to grasp, try out vi.

NAFV_P3• 12 years ago

I have trouble with my ulnar nerve which emanates from the neck, my physiotherapist noted that I have mild muscle wastage in my left shoulder.

Which editor would you recommend, should I quit Vim and try Emacs, or perhaps another editor?

ClashTheBunny• 12 years ago

This is really a great point, and it's something that I look for in any new editor I try. I want verbs and directions, not complete predicates. If I create a new verb, I want it to work on all other directions out there. I don't want to have to go through and think "Is M-k used for anything yet?".

nathansobo• 12 years ago

Have you tried our vim-mode package? It's not perfect yet, but it's getting closer. It's built around an op-stack and is designed to be compositional. We definitely understand the points made in this article, and it's very possible to implement modal editing in a package. Extensibility vs compositionality is a false dichotomy.

cies• 12 years ago

Like `evil` for emacs. The predecessors of evil (vimpulse and viper) did not cut it for me; but since evil I could not resist the switch.

I like the atom effort, and I think it may come a long way. But it also still has a long way to go until it is as mature as emacs.

Another good thing of emacs that I only recently started to appreciate is LISP --the grandpapa of all dynamic languages-- that is used for both emacs scripting and config-file format (they are kind of the same). JavaScript, how ubiquitous it may be, will never be as "impartial" and "timeless" as LISP.

roryokane• 12 years ago

The good thing about JavaScript, however, is that it has become a compile target for many languages. You could theoretically write an Atom plugin in any language that compiles to JavaScript, even a Lisp-based one like ClojureScript.

mkozlows3• 12 years ago

I certainly don't think it's a dichotomy; I explicitly want an editor that combines composability with extensibility.

And while vim-mode is impressive, I don't think it's really quite enough, unfortunately. Because the problem is that vim-mode isn't core to Atom's design philosophy, it's a bolt-on that tries to import a different philosophy to Atom. Other extensions (and native commands) don't expect to be in vim-mode and don't natively work in a way that extends vim-mode.

s_kilk• 12 years ago

I've tried atom with vim-mode, and it's not enough to replace either vim or emacs-with-evil-mode in my toolbox, not even close.

While the vim keybindings and modes in the editor are ok, it really lacks the keyboard-driven window and panel control you have with vim. Basically, the UI still needs to be driven with a mouse, which totally breaks my workflow. As another commenter put it, vim-mode is a bolt-on, rather than an integral part of the editor.

mparramon• 12 years ago

By the way, if you want to disable the popup for special characters in Mac OS X, here's how: http://www.developingandstuff.com/2014/06/disable-long-press...

fulafel• 12 years ago

) looking at modern editors like Sublime Text and Atom, is how Emacs’ big idea has been thoroughly learned

There is no other popular editor that goes out of its way to show it's modifiable at every turn. Emacs is really asking for it.

Well I haven't seen atom since I don't have a Mac but I'm prepared to risk the statement!

csirac22• 12 years ago

I find "!" fun. Mark a region (or spell it out in the : prompt), and use it to run the region through any external script/binary which takes STDIN and emits to STDOUT.

Eg.:

  :%! perltidy       # runs whole buffer through perltidy
  :123,456! jsontidy # run lines 123..456 through jsontidy
  !} htmltidy        # htmltidy to end of para

vram224• 12 years ago

A nice use of the ! command in vim, is if you have a text files with lines and you want to sort it; do this, in command mode:

!Gsort

The ! command can also sort just a range of lines (in place, in the file), which can be even more useful. The range can be selected either by start and end line numbers, as in the parent comment's 2nd example, or by start and end marks (set by ma, mc, etc.) or even by a combination of the two, e.g. starting line number, end mark:

:'a,'b!sort :123,'b!sort

Another example - turn a list of constant definitions in your code, into uppercase:

!Gtr [a-z] [A-Z]

And so on ...

vram224• 12 years ago

Edit: After reading the OP, I realized that my example of uppercasing constant definitions, can be simpler with this vim command, which doesn't shell out to the tr command:

gUG

(uppercase U in the command, as opposed to the OP's use of guG - lowercase u).

vram224• 12 years ago

Edit 2: Also, vim has a built-in sort command:

http://vim.wikia.com/wiki/Sort_lines

, so for the sort example I gave, too, you may not need to shell out to the external sort command. On the other hand, you may want to, since it has more functionality.

Plus, vim doesn't have every filter command that Unix does, so the ! command is still very useful.

csirac22• 12 years ago

Gsort is cool! I usually defer to my blunt instrument approach of just doing ! sort. Vim is one of the few tools that keeps rewarding me more and more, the longer I use it.

__david__3• 12 years ago

M-| on emacs. I use it all the time for "diffstat".

irremediable2• 12 years ago

I'm very excited about Neovim: among other things, it's going to allow the use of alternatives to VimScript, and a proper GUI.

pyre• 12 years ago

There are already alternatives to VimL. You can use Python, Ruby, etc.

thristian• 12 years ago

"Alternatives". VimL lets you set and inspect options, invoke other functions, all kinds of stuff. The other language bindings (particularly Python, but I assume this is true of the others) give you a high-level list of open files, the ability to send individual key-strokes to Vim and the ability to eval a VimL expression. All the vaguely-complex plugins I've seen have some sort of algorithmic core implemented in another language, and a whole bunch of VimL to wire the core up to Vim.

sigzero• 12 years ago

I was wondering when this would pop up. Smh

irremediable2• 12 years ago

What does "smh" mean?

goldfeld4• 12 years ago

After switching from Vim to Emacs (but keeping my hardcore modal editing muscle habits through evil-mode), I realized why most hardcore Emacs users have never felt the need for this raw composability of commands and motions (which I love): hardcore Emacs users tend to be lispers, and lispers have Paredit, and that works on such a higher level of editing that you don't need raw composability. It only works for something as homogeneous as s-expressions though.

There might as well be no concept of "words" or "lines" in a seasoned lisp programmer's mind, there's only sexps and forms. And it's so much easier to reason that way, which is not a fault of vi's grammar but arguably a fault of most programming languages' grammars. It's that fabled saying that you should rather have one data structure (sexps) with 100 operations on it than 10 structures (words, lines, bracketed expressions, paras) with 10 operations each. Vi at least makes those operations consistent across structures and thus trivially deducible.

I tend to use vi-bindings in my Emacs coding (Clojure), but I'm more and more relying on Paredit. However I'm immensely happy to have vi commands for editing prose on Emacs, and I don't think there's anything more powerful than vi for that.

guns• 12 years ago

There might as well be no concept of "words" or "lines" in a seasoned lisp programmer's mind, there's only sexps and forms

Forgive me for plugging my own project, but vim-sexp¹ provides exactly this abstraction as Vim text-objects, which in turn may be composed with _any_ of the operations in Vim.

S-expressions as text-objects is an amazing marriage of ideas. For example, the sexp text object can be used equally as an argument to eval, yank, delete, change, select, move, and every other operator, builtin or user-defined, each optionally accepting a count. After that, the whole operation can be repeated on a new S-expression with a simple tap of the repeat command. Because Lisp forms are so regular, these actions are precise and highly reliable.

¹ http://github.com/guns/vim-sexp

jacques_chester• 12 years ago

It's that fabled saying ...

The origin of this saying is Epigrams in Programming, by Alan Perlis.

http://www.cs.yale.edu/homes/perlis-alan/quotes.html

tikhonj• 12 years ago

Actually, you can have paredit-style structured editing for whatever languages you want to support. For example, there is a pretty capable structured editing mode for Haskell[1], which has a syntax significantly less regular than s-expressions. (On the other hand, it's still more regular than most languages...)

[1] https://github.com/chrisdone/structured-haskell-mode

59nadir• 12 years ago

There might as well be no concept of "words" or "lines" in a seasoned lisp programmer's mind, there's only sexps and forms. And it's so much easier to reason that way, which is not a fault of vi's grammar but arguably a fault of most programming languages' grammars. It's that fabled saying that you should rather have one data structure (sexps) with 100 operations on it than 10 structures (words, lines, bracketed expressions, paras) with 10 operations each.

This really can't be overstated.

Even if you don't really use Paredit or any kind of special tool S-expressions lend themselves to easy modification. Since a Lisp program is, by virtue of the structure, organized by default into easily separated components there is no need to think about anything else other than just expressions.

When I write Racket code (in Emacs), I organize and move code in expressions instead, and if I wanted to move a certain expression I would just move to the enclosing paren and hold shift while saying "move to matching paren" and the whole expression will be marked and I can do whatever I want with it.

I used to use vim before and while I did "get it" after a while I switched to Emacs when I started learning Lisp because I figured I could immerse myself in Lisp code with Emacs.

The thing about it is that since I've coded almost exclusively in Lisps since then I haven't really needed what vim does best. At some point a while ago there were a slew of posts about vim and I looked at maybe getting evil-mode for emacs, but I don't know if I see the point when I almost exclusively deal with sexps.

deng2• 12 years ago

The article claims that "Emacs’ big idea has been thoroughly learned", but I beg to differ. Having an extension language which lets you define functions and bind them to keys does not make you "Emacs". The big idea of Emacs (which of course it got from the Lisp machines) is self-hosting: Emacs is written in Emacs Lisp. There is no separate extension language. Yes, there is a core written in C, but it is very small, and there is an ongoing effort to move functions from there to Emacs Lisp (lots of stuff was put in the C core for performance reasons, but nowadays our machines are just so much faster). Since it is all interpreted and Lisp, you can redefine anything at runtime, down to the core (which of course implies that you're free to render Emacs unusable without any problems). Emacs surely isn't alone here; maybe Atom works the same, and I guess LightTable does, too. But he mentions SublimeText, which doesn't work this way. I think we're still far away from "thoroughly learned".

rbanffy2• 12 years ago

In that, Emacs is very close to Smalltalk environments. Everything you see on the screen is a Smalltalk object and its behavior can be redefined at will. I'm not sure how much the design was influenced by Lisp machines or Emacs itself.

I once crashed a Squeak image by telling it "true := false".

Since then constants became a little more constant.

marktangotango• 12 years ago

This has been called the "Emacs Thesis". Google returns this as the first link:

https://www.gnu.org/software/guile/manual/html_node/The-Emac...

aidenn02• 12 years ago

I thought GNU emacs was written in C.

deng2• 12 years ago

As I've written, there is a core written in C. The ratio of Emacs Lisp vs C is about 80/20. 20% might look rather large at first, but if you keep in mind that Emacs supports a large variety of operating systems (from MS-DOS(!) over Windows, OSX, Linux, *BSD to various other Unix flavors like AIX and Solaris), and also supports various toolkits (like Lucid/Athena and GTK), it actually isn't that much. Most of the C code works as a sort of hardware abstraction layer, providing a common interface to the Lisp layer for handling (bidirectional) display, processes, memory, and so on. Compared to that, the actual Lisp interpreter is tiny.

__david__3• 12 years ago

So a quick run of "cloc" in my Emacs bzr directory shows:

    ----------------------------------------------------------------
    Language      files          blank        comment           code
    ----------------------------------------------------------------
    Lisp           1608         148211         196355        1073066
    C               255          52208          62868         246635
    ...

Mostly lisp, with a good chunk of C at the core.

jv_dh• 12 years ago

this article fails to point out that one of the great advantages of vim is universal accessibility. while atom, sublime, textmate are probably more user-friendly and can emulate a lot of vim functionality, they are not as flexible and environment-independent.

to me, the beauty of vim is that I can use it anywhere with minmal set-up or privileges (e.g. root).

emeraldd• 12 years ago

Dead on! This is the biggest reason to know vi period.

johnchristopher• 12 years ago

This really read more like Vim vs Emacs than Atom vs Vim (And I say that without any prejudices against Atom or Emacs).

1782• 12 years ago

I would strongly disagree that atom commands are not "composable" (though it depends on your workflow/mental model). To take the select/delete example: atom can select to the end of the line, and it supports the delete key. How is select-than-delete not composition?

falcolas4• 12 years ago

You can apply modifiers to VI's composable objects. For example, you can prepend a 3 to the deletion operation, and delete three words, lines, or paragraphs.

You could replicate this by starting a selection and manually moving to the end (either by a combination of commands), but it looses its coherency as a single expression to be executed.

In the words of someone smarter than me, you have a conversation with vim - "delete three words", whereas you micromanage another editor - "start selection, move one word, move one word, move one word, delete".

krautsourced• 12 years ago

But, on the other hand, sublime/atom/... will give you immediate visual feedback about what it is going to delete (the marked range), whereas "delete three words" can potentially be open to ambiguity (plus you have to count words in advance...). For example, some editors consider my-function() a word, others stop the word at the "-" etc.

I understand why in some cases the kind of low level power you get with editors like vi and emacs etc is of an advantage, and I use vi regularly myself for basic editing on remote shells, but I am more of a visual person and I much prefer the usability over power approach.

ulisesrmzroche3• 12 years ago

You can always just select stuff with your mouse and press the delete key. We're writing code, not prose, here. When was the last time you used paragraphs anyway?

Symmetry• 12 years ago

What I really want is an editor with both a jump list and a yank ring.

Tyr42• 12 years ago

http://www.vim.org/scripts/script.php?script_id=1234

You can add a yank ring to vim.

teeray• 12 years ago

It's sad that Acme hasn't been mentioned at all. While its mouse-oriented nature is a little strange coming from Vim, there are some very awesome ideas in it. For one: It lets you write plugins in anything you like. This is because all aspects of the editor are exposed as a filesystem a la /proc. Need to create a new window with some custom contents? Create a new file. Other awesome ideas: The text in that custom window can be actions because any text can invoke commands by using another mouse button.

Russ Cox has a great video tour of Acme's features here: http://www.youtube.com/watch?v=dP1xVpMPn8M

wingerlang• 12 years ago

Interesting but I feel the constant switching between mouse and keyboard would get annoying really fast.

aidenn02• 12 years ago

The theory is that it's modal like vim; when you are entering text, you have both hands on the keyboard; when you are manipulating text, you have one on keyboard and one on mouse.

discreteevent• 12 years ago

" The basic summary is cursoring around required a higher level of mental planning to organize the interaction, which apparently obscures the perception of the passage of time--think of being deeply engaged in something and being surprised when you look at a clock-- whereas the use of the mouse was done at a lower, mechanical level that left the mind free for higher things, such as complaining about the mouse."

http://plan9.bell-labs.com/wiki/plan9/Mouse_vs._Keyboard/ind...

lord_quas2• 12 years ago

Wow, there are some really cool and unique ideas in this editor. Thank you for sharing.

I am of course so ingrained in the emacs way that I probably will never change editors.

weslly• 12 years ago

The concept of Acme remembers me of Xiki[1]. It would be perfect with better fonts and/or code highlighting.

[1] https://www.youtube.com/watch?v=bUR_eUVcABg

dagi3d• 12 years ago

the thing I miss the most in vim compared to other editors is a faster search in project feature. I guess most "modern" editors preload the whole directory in the background something that might not be feasible with vim today. hope to see an improvement with neovim in a near future

chrisfarms• 12 years ago

Ag [1] has served me very well if you haven't come across it.

[1] https://github.com/rking/ag.vim

pmoriarty7• 12 years ago

There are also plugins like ctrl-p:

http://www.bestofvim.com/plugin/ctrl-p/

icantthinkofone• 12 years ago

"you need to install a half-dozen third-party plugins (and a third-party plugin manager at that) to get basic functionality working; "

What? I've never installed half a dozen anything to vim, and some of my machines don't have anything added to them, so I don't know where he's coming from.

falcolas4• 12 years ago

For a long time, neither did I. Then I found a number of packages which make editing in vim, not better, but easier.

Of course, I don't find it to be all that hard to re-create my working environment: simply copying my .vim and .vimrc from one machine to another "just works".

jqm2• 12 years ago

Exactly. .vim and .vimrc are always the first things transferred upon setting up a new machine or server.

Usually directly after I open the first configuration file on the new box in vim and have a "what the heck??" moment when it doesn't behave as expected.

ilaksh• 12 years ago

Fairly sure what I am going to say won't be popular and will probably make me lose 'face' among many programmers, but I will say it anyway in case it can help anyone who still has an open mind about this.

Around the time Windows came out I had a PC and learned how to edit files with it. I learned to select things (character, paragraph, end of line etc) using combinations like shift-arrow, control-shift-arrow, shift-end, and copy-paste with control-c, control-v. It has always seemed intuitive to me and works well.

I believe that the reason that vim and Emacs have different keys and ways of editing which are less intuitive to me is because they were created in an earlier and more primitive era. I believe those interfaces are inferior.

Now, I do use vim on a daily basis because I can use it when I shell into a remote machine and because there is almost always syntax highlighting available for any given language. So it is my everyday editor. When I want to indent, I use visual mode. If I want to copy a few lines sometimes I use visual mode, or I use the mouse and the copy and paste menu options in the terminal right-click menu. Or shift-insert to paste.

If I want to increase the indent, copy, etc. in vim, I can select/mark an area and do like I just explained. If I were in Atom, I would use the nice shift-arrow and control-shift-arrow stuff. I don't feel that it is important to be able to parameterize those operations the way he suggests, because I have adequate and/or nicer less primitive ways of doing it.

Its pretty amazing to me how the same people who can look at a web application and complain about a minor usability issue like not having an autocomplete for a search field can go into their editor from 1976 and think that all of the old fashioned cryptic keyboard interface schemes are the best thing ever.

Anyway, the only reason it can't replace vim, which he didn't mention, is that it doesn't run in the terminal, and sometimes that is more convenient.

awakened• 12 years ago

"I believe those interfaces are inferior."

Things are not inferior or superior, they are only different. If you can open your mind and understand this, then you will realize vi and Emacs for what they are.

ddoolin• 12 years ago

I get the exact opposite sentiment reading in this thread. Everybody seems to think vi/Emacs are perfectly superior to graphical editors.

I honestly _cannot_ believe people are still writing posts like the OP did. It's getting so old to even talk about it. Yeah yeah, nobody ever said Atom would replace vi or Emacs. They'll live forever...we get it.

goldfeld4• 12 years ago

The moment I read "I believe those interfaces are inferior", my mind started dumping half a dozen paragraphs of ranting, but that would be painful to write, so I'll just leave it at an analogy to try and make you see how you're the one being closed minded here:

That's a bit like a native Esperanto speaker saying "I don't know what's all the fuss about English being a lingua franca, I learned how to say hello and goodbye and I don't feel I can access all that wealth of knowledge people claim is available to them." Obviously they would have said that in Esperanto, but I don't know it.

Karunamon• 12 years ago

Heh, you made me go to google out of curiosity.

"Mi ne scias kio estas tuta vanti angla estante pontolingvo, mi lernis kiel diri saluton kaj adiaŭo kaj mi ne sentas mi povas aliri ĉiujn kiuj riĉeco de scio personoj asertas disponeblas al ili."

Esperanto seems roughly as dense as english, maybe slightly less.

javajosh• 12 years ago

That's a thoughtful post, and you shouldn't be afraid to say that something is inferior or superior (and "in my opinion" is assumed). My first programming experiences were on the Apple IIe, and it was much more similar to Windows than to vi or Emacs, and I don't believe my ability to edit files was particularly harmed by not using these editors.

Moreover, although I use vi on occasion (because it's ubiquitously installed and readily accessible in a terminal) I don't like it at all. It fails almost totally on the level of discoverability. That is, those wonderfully composable commands are impossible to discover in vi itself. It also fails at the level of giving good feedback about what you're doing right now. Finally, it fails because it's confusing because modal editing is confusing. It makes much more sense to me to use "out of band" input (like meta keys and mouse input) which is psychologically orthogonal to actually entering text. Not to mention the fact that in situations where you want to move and edit a lot, you actually add a LOT of keystrokes.

I agree that composability is a very cool feature of vi, but the negatives dominate this. (This is the reverse argument that people seem to ignore about javascript: the ubiquity and power of js absolutely dominates, by several orders of magnitude, it's weaknesses as a language and runtime.)

In any event, arguing about text editors truly is like religious argument: if you enjoy using emacs, vi, or notepad, I'm happy for you! In the end, if it works for you then it's good, and it seems rather counter-productive to try to convince people one way or another.

SoftwareMaven2• 12 years ago

I disagree that Emacs doesn't start at the level of composability; it just has very different expectations of its users. Emacs "big idea" is the programmability of the environment, therefore, its composability is at the level of lisp functions. The very best Emacs users take advantage of composability at this level through keyboard macros, evaluating expressions, and building new commands.

Vi took to the unix philosophy: it's all here and can be composed as you need. Even with Vim's extensibility, it hasn't gotten close to Emacs at the functional level of composability.

Sublime, et al, took as Emacs "big idea" the same thing the author did, "you can create commands", but that is too narrow of a view, and that's why those editors haven't displaced Emacs.

On that topic, Emacs is also a multi-mode editor. There is editing mode, which most people are familiar with, and there is programming mode, where one makes the editor more able to handle the problems one is facing. Until one masters programming mode, Emacs will just seem to be the "editor with cumbersome key mappings".

sergiosgc• 12 years ago

You don't get Vim. Its composability is at the user interface level, not at the extensibility level. It's a different editor, tough to learn but incredible when you pass a certain threshold.

I've used emacs for about a decade, and Vim for about another. I switched to Vim for practical reasons but place both editors at equivalent levels of quality. Both are great. Not perfect, but great. The article is spot on at identifying the core lessons in each.

lord_quas2• 12 years ago

Check out evil-mode in emacs. Its wonderful.

mrottenkolber2• 12 years ago

There are multiple Vi modes for Emacs but not a single Emacs mode for Vim.

SoftwareMaven2• 12 years ago

I'm not really commenting on vim. I actually had a previous comment written where I said almost exactly what you said. I'm not even saying one is better than the other, just that the author's understanding of Emacs was, IMO, less than complete.

The funny thing is both vim and Emacs have these weird learning curves: Emacs starts easier (you can actually type something; wtf is a mode?!), then vim becomes easier (modes and command composing over finger gymnastics and pages-long key bindings), then (and this is, of course, my opinion) Emacs with its programmable everything starts to shine. I wonder how much of the editor wars are simply where people are along that continuum.

alwillis2• 12 years ago

I’ll bring out the one of the more influential articles on Vim to further explain the author’s point—Your problem with Vim is that you don't grok vi: https://gist.github.com/nifl/1178878

pmontra• 12 years ago

I started using vi in 1987 and switched to emacs in 1991. The macro recorder sold the editor to me. Then I scripted everything I could (I have fond memories of a mail client call vm) and eventually forgot most of elisp in the 2000's.

I still use vi (vim, actually) when I ssh to servers for quick editing local configuration files. I agree that command composability and . (don't forget the dot command) are great and I sometimes miss them in emacs, especially the dot command which is like automatically defining a macro for the last command and running C-x e with a single keypress. I think this might be the defining tract of vi as much as ESC and command composability.

All considered I still prefer emacs to the vastly improved vim we have nowadays. I just don't want to have to press ESC all the time before moving to another place in the edit buffer. I wonder if somebody could come out with a great idea for merging the two paradigms in some natural way. I'd love to have both emacs and vi in the same editor.

omilu• 12 years ago

evil mode comes pretty close

jqm2• 12 years ago

I don't want to press escape all the time either. But some "nmap" entries in vimrc takes care of most of that.

This article is right... vim does take some customization to make optimally (and personally) useful.

Rusky• 12 years ago

A lot of people remap esc to caps lock, which is roughly where the esc was when vi was created. Out of the box, there's also ^[ (ctrl+[), which is what I tend to use.

octref• 12 years ago

I find it funny that neither the original blog post nor the comments here really talks much about "Why Atom can't replace vim". The reason why Atom can't replace Vim, at least for me, is Atom is painfully slow due to the gigantic DOM tree behind it.

general_failure• 12 years ago

Yeah the article sort of ended abruptly.

mkozlows3• 12 years ago

Performance is temporary, design is forever.

(Remember that the slur against Emacs -- itself once considered by some too heavyweight to compete with vi -- was that it used "eight megs" of memory.)

Gracana• 12 years ago

When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a “viitor”. Not a “emacsitor”. Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!

For the uninitiated: http://www.gnu.org/fun/jokes/ed-msg.html

vidarh• 12 years ago

For the uninitiated: "Eight Megs And Constantly Swapping"

This page has lots more: http://www.gnu.org/fun/jokes/gnuemacs.acro.exp.html

ibrahima3• 12 years ago

I think for a lot of hackers, being able to run from over a terminal/ssh is a critical "design" feature.

omershapira2• 12 years ago

It's funny how this idea exists in every paradigm I can think of.

In video editing, Avid Media Composer has an unparalleled function composition feature. All of the UI depends on it - the alt-keys form related commands, every tool has a semantic that you can't escape. In Avid, you can only edit the keybindings for keys with/without shift pressed. No alt-pressed or alt-shift etc. Semantics of all of these come overloaded out of the box.

Final Cut and Premiere are a completely different thing. Infinitely customisable, you can define any key (or cmd-key or cmd-fn-alt-shift-key) to do any thing. What a redundant idea. Tools don't carry any semantics, so if you're trying to, say, trim 10 frames forward, but you're not in trim mode - error beep. In Avid, the idea of modes is so powerful that each function key has maximum functionality outside that mode.

It's a shame how many UI designers get it wrong.

goldfeld4• 12 years ago

That's fascinating! I have ofttimes felt the urge to learn a good video editing workflow as a hobby (though haven't as of yet gotten around to it), and I'd never have known of this heaven-and-hell difference without experiencing the pain first hand. I know these tools tend to overlap with DAWs, but do you know about this automation/productivity landscape on the side of audio production and editing?

omershapira2• 12 years ago

Video editing features are all quantised to one frame – that's why Avid shows that frame as a range, not a point. Audio editing tends to be continuous rather than discreet, so it's a different UI strategy. There's no "end of word" to speak of, there's "end of beat", and I can't really tell you about that. I will tell you that I couldn't find any DJ tool which matches Avid's semantic level. One that comes very close is the Serato Itch, along with the Novation Twitch controller - overloaded semantics on every command, sharp mode separation, at no compromise over control.

pothibo2• 12 years ago

Atom cannot replace vim because you can have the very same vim setup on your desktop AND your server. You would need a GUI on your server to share that portability. Now, this may not be an answer to the article but it's the reality.

If the author wanted a better comparison he would have chosen Sublime Text, Textmate or any other GUI based editor.

chr1• 12 years ago

Then can online editors like cloud9 replace vim? They can easily connect to any server and provide same ui for server and desktop.

pothibo2• 12 years ago

The comparison is indeed more relevant.

curun1r• 12 years ago

Two points: - The move from server administration to devops has made editing files on servers much less necessary. We should be treating our server environments like the output of a deployment function rather than a stateful, manually-created environment. - GUI editors like Atom have had SFTP integration for a while and it would be quite simple to add remote editing capabilities to Atom.

pmoriarty7• 12 years ago

emacs is every bit as composable as vim, as with vim emulators such as evil-mode[1], emacs is a superset of vim.

[1] http://www.emacswiki.org/emacs/Evil

alwillis2• 12 years ago

Nope--it’s not the same: https://news.ycombinator.com/item?id=7828825.

pmoriarty7• 12 years ago

You linked to a post which talks about regular Emacs, not Emacs with evil-mode emulating vim.

With the latter, it's every bit as composable as vim, as you can use vim keystrokes to edit in Emacs.

Take the "dt>" example from the post you linked to. You can do that directly in Emacs using evil-mode by typing those exact keystrokes. There's absolutely no difference.

bhuga• 12 years ago

This article picks on Atom, but it's really arguing Vim vs Every Other Text Editor based on composed commands vs monolithic commands.

I agree that Vim's style of composed commands is somehow more natural. But Atom's core value is hackability. Atom's vim-mode package performs every operation in the article and countless more, and does it all without any special APIs or permissions. The commands that are not in the editor API, or are but are slightly different from Vim, are written using editor primitives. That hackability is Atom's special sauce, not the set of convenience commands the editor API supports.

Sublime would have been a better "target" for this comparison.

MarcScott• 12 years ago

This is off topic, but I've always wanted to know if there is some reason that Mac OS supports so many of the Emacs editing commands? C-a, C-e, C-f, C-b, C-k, C-d all work. It often surprises me when I'm in some other app and accidentally use an Emacs command, only to find that it works.

protomyth2• 12 years ago

Its part of Cocoa, search for ~/Library/KeyBindings/DefaultKeyBinding.dict for more information and how to alter the behavior.

jaequery• 12 years ago

It's part of unix/linux, they all have emacs keybindings as default

huxley• 12 years ago

It comes from NeXTSTEP, text fields were given several emacs compatible keystroke editing commands as part of the key bindings for NSTextField and NSTextView.

You can modify the default keybindings and even add more emacs compatible keystrokes if you find it helpful and most Cocoa apps will inherit the new keystrokes: http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html

(it's a good article that also has some interesting info on Input Managers and modifying keyboard layouts)

drdrang wrote an article that linked to several other good sources on the subject:

http://www.leancrew.com/all-this/2011/11/capitalization-keyb...

ulisesrmzroche3• 12 years ago

I switched to Vim because my left pinky was getting numb, *(thanks vim!) and then to Sublime, and now, Atom, for aesthetic reasons, really. Easier to read, I don't wanna wind up needing glasses. I'm still using the vim packages though.

pmoriarty7• 12 years ago

You don't have to abandon vim just because of pinky strain.

You could just remap jj or jk to ESC.

judk2• 12 years ago

Parent was saying they left emacs for pinky strain.

How can you use regular letters in place of ESC in vim? How would you type "Dijkstra"?

emsy• 12 years ago

Did a quick search 128 occurrences of emacs, 127 occurrences of vim and 28 occurrences of atom

As a long-time vim user I'm very excited for a new cross-platform text-editor when I need a mode-less editor. I use vim for different purposes.

myspy• 12 years ago

Some words to editors from my side.

On work, we deploy our site to customers on Win Servers. We use Notepad++ on them. It's the shittiest editor, I've ever used.

On my own machine I'm able to use Sublime. From time to time Brackets. We use self-made IDEs for our own stuff. It's pretty awkward.

Ever used SE80 in SAP? That's the pinnacle of crappy editors.

On my after work machine I test Atom at the moment, I quite like it. The git integration is nice.

And I also used vi/emacs, but only briefly. I use a German layout with my keyboard, but everything is designed with the US layout in mind. Therefore, many things don't work, and I wasn't able to learn the US layout yet.

Vi/Emacs not bad, but takes a lot of time to customize and learning all the commands. I'm not even sure if it makes me anymore productive.

But the business programmer world is full of Eclipse and other IDEs. Using an editor like Sublime is madness here.

welterde• 12 years ago

And I also used vi/emacs, but only briefly. I use a German layout with my keyboard, but everything is designed with the US layout in mind. Therefore, many things don't work, and I wasn't able to learn the US layout yet.

I don't have any issues with using emacs and a german keyboard (and haven't come across anything that didn't work..)

wldcordeiro• 12 years ago

Business programmer here, I get to use whatever editor I choose on whatever OS I choose so currently I use Sublime Text 3 on Ubuntu and I've been testing out Atom (though I find it quite slow.)

jakejake• 12 years ago

I'm really curious about html apps being deployed in native shells and this was actually my first introduction to atom-shell. Does anybody have any experience developing with it? It appears to have everything I would need but so far I've been disappointed with just about every other solution. https://github.com/atom/atom-shell

colin_mccabe• 12 years ago

I think one thing a lot of people miss is that vi's key bindings are more ergonomic. You don't ever need to press more than one key with each hand at a time, and you don't have to take your fingers from the home row. Meanwhile a lot of emacs key combinations are like playing "twister" with your fingers, and the guy who wrote most of it (RMS) developed a crippling case of RSI.

emacs lisp is much nicer to write extensions in than vimscript, though. It's too bad vim didn't copy that part.

bdamm• 12 years ago

Indeed, although all this talk of high quality vi plugins for emacs has me considering an emacs review. I've been a vi user for over a decade now and I love it because when I am editing text I feel I am using a truly sharp knife to slice the data apart, and wonderful hand tools to piece it back together. Vim is to me as a woodworker's chest of honed block planes is to such a craftsman.

And it is mainly due to the ergonomic design. I can absolutely fly through code in vim without so much as a crick of the wrist.

pjungwir• 12 years ago

In vim I use / all the time to search, and I use f to move within the line or to say dfx or yfx or even d3fx. But is there any way to search for more than one letter without deleting/yanking the whole line? I want d/foo, but only up to foo. Is that possible?

mct• 12 years ago

This is exactly how "d/foo" works for me, both in vim, and in nvi (the "bug-for-bug" clone of the original vi). Perhaps you have a script installed that's changing the default behavior?

jrockway• 12 years ago

So, Emacs has the same ability to compose commands as Vi. If you want to delete a sentence, then you do:

(set-mark) (forward-sentence) (kill-region)

If you consider holding down bucky bit keys to be command-mode, then it's:

C-<spc> M-e C-w

I don't see how this is any different than giving "d" an argument, other than it's three keystrokes instead of two, and the fact that there's a region leaks. (Of course, in vi you still have to enter and leave command-mode, making the total number of keystrokes greater in this particular case.)

All said, I don't get this article.

MichaelMoser123• 12 years ago

... but vim is can be scripted too! the in-build scripting language is sometimes a bit awkward, but it works. here is a big repository of scripts for vim. http://www.vim.org/scripts/index.php

Why Atom Can’t Replace Vim – Learning the lesson of vi

Related Stories