15 ms·

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

475 points by jpace121 12y ago

Monkeyget 12y 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 12y 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 12y 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.
- agumonkey 12y 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.
  - lispm 12y ago
    Emacs. c-w will kill the active region.
    - agumonkey 12y ago
      Irrelevant, they're still separate logic for each kind of kill. See: 10 matches for "^(defun kill-" in buffer: simple.el.gz 3218:(defun kill-new (string &optional replace yank-handler) 3270:(defun kill-append (string before-p &optional yank-handler) 3340:(defun kill-region (beg end &optional yank-handler) 3411:(defun kill-ring-save (beg end) 3605:(defun kill-forward-chars (arg) 3611:(defun kill-backward-chars (arg) 3679:(defun kill-line (&optional arg) 3734:(defun kill-whole-line (&optional arg) 5049:(defun kill-visual-line (&optional arg) 5354:(defun kill-word (arg) Vi as one notion of deletion that is parameterized by a region(or movement in vi slang I believe), which is bound to a set of keys.
      - lispm 12y ago
        It's not irrelevant. For most uses, mark the point, move, kill-region. I vastly prefer doing operations over explicit regions, instead of composing editing operations as in vi. Especially since this maps better to other forms of editing.
        bluetech 12y ago
        vim allows you to select a region and operate on it. It sometimes necessary, but in practice, people use the compositional commands. They are faster and mentally easier. So empirically it seems your preference is different than most. Also, what do you mean, maps better to other forms of editing?
        Gravityloss 12y ago
        I think you're getting close to some important points. I think Sublime Text's multiple-cursor editing is nice because I can see where the focus is and get immediate feedback, much better than "replace-all" even if the end result would be the same. Bret Victor style. So most of the real complexity in the interface is about region-selection, and the operations are actually trivial. Of course, you need to first select regions (like interesting lines), then select other regions within those, others within those etc. How to chain it all in a natural way?
- swah 12y ago
  Mine is the pain of loving emacs and not using because of wrist pain.
lispm 12y 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 12y ago
  Emacs also have M-h to mark the current paragraph, so M-h C-w will cut the current paragraph.
- FatalBaboon 12y ago
  i simply bound flush-lines for that
- gkya 12y 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.
  - lispm 12y 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.
    - groovy2shoes 12y ago
      Just out of curiousity, what is your favorite editor?
norswap 12y 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).
- calibwam 12y 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.
  - lispm 12y 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.
    - calibwam 12y ago
      On a macro level, I agree. But switching mode isn't so hard that you have to sit twenty minutes in normal mode, thinking what you would do in the entire document, before you switch to writing it.
      - mercer 12y ago
MichaelGG 12y 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/ http://vim-adventures.com/
- anonymoushn 12y ago
  VIM Adventures looks great! I'd love to buy it, but the author is only willing to rent it.
  - MichaelGG 12y ago
    6 months at $25? Personally I feel I've gotten far more value out of it than that.
NAFV_P 12y 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 http://almy.us/teco.html
- recraft 12y ago
  Emacs was originally written as a series of TECO macros.
  - kps 12y 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.)
- lispm 12y ago
  If you think Emacs is hard to grasp, try out vi.
  - NAFV_P 12y 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?
    - goldfeld 12y ago
      If you're asking about ergonomics overall, I'd say Vim, definitely. Though a lot in both cases can be mitigated with useful remappings (use Caps Lock as Ctrl, or as Esc! Or as both! https://github.com/alols/xcape https://github.com/alols/xcape or KeyboardRemap4Macbook). Also I find Dvorak a lot more pleasant on my fingers than good ole QWERTY. I have at various different times felt a lot of strain hit some of my fingers, especially the pinkies. My right pinky complained first, and I realized how much it was used for. I first switched from Dvorak to Programmer Dvorak so that my pinky wouldn't have to do curly braces and square brackets anymore, and so that both those and parens no longer required a shift press (also helping the other pinky), since Programmer Dvorak switches numbers with symbols (the latter of which I use far more as a coder.) I also got used to Ctrl-H instead of Backspace and Ctrl-M instead of Enter, wherever I could. They didn't work in the editor's command mode, so I created mappings so that they would. The issues went away. More recently, more than a year after that, I started feeling my other pinky, the left one. I severely reduced my Tab usage and began using the Left Alt as a Left Ctrl more, so my pinky shares Ctrl usage (which was already on Caps Lock, but still..) with my thumb. Also worked. An ergonomic keyboard would also be a fine acquisition. By the way, trouble in the "ulnar nerve which emanates from the neck" leading to "mild muscle wastage" sounds quite sci-fi to me (not disbelieving, just thought it sounded rather exotic.)
ClashTheBunny 12y 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 12y 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 12y 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 12y 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.
- mkozlows 12y 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 12y 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.
fulafel 12y 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!
csirac2 12y 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
- vram22 12y 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 ...
  - vram22 12y 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).
  - vram22 12y ago
    Edit 2: Also, vim has a built-in sort command: http://vim.wikia.com/wiki/Sort_lines 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.
  - csirac2 12y 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.
irremediable 12y 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 12y ago
  There are already alternatives to VimL. You can use Python, Ruby, etc.
  - thristian 12y 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 12y ago
  I was wondering when this would pop up. Smh
  - irremediable 12y ago
    What does "smh" mean?
    - ovechtrick 12y ago
      Shaking My Head
goldfeld 12y 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 12y 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 http://github.com/guns/vim-sexp
- deleted 12y ago
  [deleted]
- jacques_chester 12y 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 http://www.cs.yale.edu/homes/perlis-alan/quotes.html
deleted 12y ago
[deleted]
deng 12y 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".
- rbanffy 12y 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 12y 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-Emacs-Thesis.html https://www.gnu.org/software/guile/manual/html_node/The-Emac...
- aidenn0 12y ago
  I thought GNU emacs was written in C.
  - deng 12y 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.
jv_dh 12y 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 12y ago
  Dead on! This is the biggest reason to know vi period.
johnchristopher 12y ago
This really read more like Vim vs Emacs than Atom vs Vim (And I say that without any prejudices against Atom or Emacs).
178 12y 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?
- falcolas 12y 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 12y 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.
    - 178 12y ago
      I couldn't have said it better. Also, I have yet to see a more compelling example of clever composition in vim than "delete 3 lines" (which even I do when rarely using vim).
      - falcolas 12y ago
        How about correct everything inside these parenthesis/brackets? Or indent everything within these brackets? Or do a search/replace over only the next paragraph? Or Title Case everything up to the next colon/semicolon/quote? Read the contents of file <x> into my current buffer? Format everything within these two matching quotes? Every movement is composable with every action. There's a lot of movements, and a lot of actions. Delete three lines is the simplest possible command, but it's hardly the only one.
Symmetry 12y ago
What I really want is an editor with both a jump list and a yank ring.
- Tyr42 12y ago
  http://www.vim.org/scripts/script.php?script_id=1234 http://www.vim.org/scripts/script.php?script_id=1234 You can add a yank ring to vim.
teeray 12y 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 http://www.youtube.com/watch?v=dP1xVpMPn8M
- wingerlang 12y ago
  Interesting but I feel the constant switching between mouse and keyboard would get annoying really fast.
  - aidenn0 12y 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.
    - kps 12y ago
      Which goes all the way back to the beginning: Englebart's NLS, which had a mouse on the right and a chord set on the left of the keyboard. (Go watch The Mother of All Demos if you've forgotten; I'll wait.) The Xerox Alto borrowed the chord/mouse pair; then the Xerox Star team found the chord set too hard for normal people to learn, and substituted dedicated function keys on the left of the keyboard, still designed to be paired with the mouse. (Incidentally, while we're talking editors, Star had a MOVE key instead of CUT and PASTE, because it was a user interface principle that there be no hidden state.)
    - judk 12y ago
      Yes but whe editing programs we are constantly alternating between insertion and manipulation every few seconds. Acme with keybindings for chord actions might be interesting
dagi3d 12y 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 12y ago
  Ag [1] has served me very well if you haven't come across it. [1] https://github.com/rking/ag.vim https://github.com/rking/ag.vim
  - pmoriarty 12y ago
    There are also plugins like ctrl-p: http://www.bestofvim.com/plugin/ctrl-p/ http://www.bestofvim.com/plugin/ctrl-p/
icantthinkofone 12y 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.
- falcolas 12y 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".
  - jqm 12y 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 12y 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 12y 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 12y 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.
SoftwareMaven 12y 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 12y 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_quas 12y ago
    Check out evil-mode in emacs. Its wonderful.
    - platz 12y ago
      I wasn't much a fan last time I tried it. If you know more than the very basic vim movements, you'll find they start conflicting with the emacs keybindings; and it's frustrating to remember which one does which. In emacs i just gave up and tried to learn vanilla emacs even though i am a vim user.
pmontra 12y 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 12y ago
  evil mode comes pretty close
- jqm 12y 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 12y 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 12y 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 12y ago
  Yeah the article sort of ended abruptly.
- mkozlows 12y 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 12y 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 http://www.gnu.org/fun/jokes/ed-msg.html
  - vidarh 12y ago
    For the uninitiated: "Eight Megs And Constantly Swapping" This page has lots more: http://www.gnu.org/fun/jokes/gnuemacs.acro.exp.html http://www.gnu.org/fun/jokes/gnuemacs.acro.exp.html
  - ibrahima 12y ago
    I think for a lot of hackers, being able to run from over a terminal/ssh is a critical "design" feature.
    - spopejoy 12y ago
      Arrgh. Emacs on the terminal is a joy, and is present on more servers than you think (dreamhost for instance). Having said that I default to 'vi foo.txt' on the command line and feel like vi competency is a core server skill ...
omershapira 12y 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.
- goldfeld 12y 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?
  - omershapira 12y 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.
pothibo 12y 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 12y ago
  Then can online editors like cloud9 replace vim? They can easily connect to any server and provide same ui for server and desktop.
  - pothibo 12y ago
    The comparison is indeed more relevant.
- curun1r 12y 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.
pmoriarty 12y 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 http://www.emacswiki.org/emacs/Evil
- alwillis 12y ago
  Nope--it’s not the same: https://news.ycombinator.com/item?id=7828825 https://news.ycombinator.com/item?id=7828825.
  - pmoriarty 12y 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 12y 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 12y 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.
- protomyth 12y ago
  Its part of Cocoa, search for ~/Library/KeyBindings/DefaultKeyBinding.dict for more information and how to alter the behavior.
  - jaequery 12y ago
    It's part of unix/linux, they all have emacs keybindings as default
    - protomyth 12y ago
      MarcScott asked about Mac OS and the unix subsystem isn't the part on Mac OS that provided the emacs bindings for the apps.
    - ibrahima 12y ago
      You're probably thinking of readline[1] actually. At the least that's why bash supports emacs keybindings (though I am never sure if a feature is from the shell or the terminal emulator). I believe you can configure readline to have vim keybindings. [1] http://en.wikipedia.org/wiki/GNU_Readline http://en.wikipedia.org/wiki/GNU_Readline
- huxley 12y 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 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-keybinding/ http://www.leancrew.com/all-this/2011/11/capitalization-keyb...
ulisesrmzroche 12y 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.
- pmoriarty 12y ago
  You don't have to abandon vim just because of pinky strain. You could just remap jj or jk to ESC.
  - judk 12y 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"?
    - pmoriarty 12y ago
      Just type jk slowly. Also see [1]: :help timeoutlen and :help ttimeoutlen [1] - http://vimdoc.sourceforge.net/htmldoc/options.html#%27timeoutlen%27 http://vimdoc.sourceforge.net/htmldoc/options.html#%27timeou...
      - isbadawi 12y ago
        Alternatively, you can type jjkak (insert a j, exit insert mode with cursor on the j, enter insert mode one character to the right, insert a k).
    - Syssiphus 12y ago
      http://vim.wikia.com/wiki/Avoid_the_escape_key http://vim.wikia.com/wiki/Avoid_the_escape_key See the 'jj' part in the 'Mappings' section.
    - rbonvall 12y ago
      Just like in the shell, anything prepended with Control+V will be input literally, so you can type Dij<C-v>kstra.
emsy 12y 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 12y 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 12y 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 12y 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 12y 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 https://github.com/atom/atom-shell
colin_mccabe 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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 http://www.vim.org/scripts/index.php

475 points by jpace121 12y 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 12y 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 12y 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.

agumonkey 12y 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.
- lispm 12y ago
  Emacs. c-w will kill the active region.
  - agumonkey 12y ago
    Irrelevant, they're still separate logic for each kind of kill. See: 10 matches for "^(defun kill-" in buffer: simple.el.gz 3218:(defun kill-new (string &optional replace yank-handler) 3270:(defun kill-append (string before-p &optional yank-handler) 3340:(defun kill-region (beg end &optional yank-handler) 3411:(defun kill-ring-save (beg end) 3605:(defun kill-forward-chars (arg) 3611:(defun kill-backward-chars (arg) 3679:(defun kill-line (&optional arg) 3734:(defun kill-whole-line (&optional arg) 5049:(defun kill-visual-line (&optional arg) 5354:(defun kill-word (arg) Vi as one notion of deletion that is parameterized by a region(or movement in vi slang I believe), which is bound to a set of keys.
    - lispm 12y ago
      It's not irrelevant. For most uses, mark the point, move, kill-region. I vastly prefer doing operations over explicit regions, instead of composing editing operations as in vi. Especially since this maps better to other forms of editing.
      - bluetech 12y ago
        vim allows you to select a region and operate on it. It sometimes necessary, but in practice, people use the compositional commands. They are faster and mentally easier. So empirically it seems your preference is different than most. Also, what do you mean, maps better to other forms of editing?
        Gravityloss 12y ago
        I think you're getting close to some important points. I think Sublime Text's multiple-cursor editing is nice because I can see where the focus is and get immediate feedback, much better than "replace-all" even if the end result would be the same. Bret Victor style. So most of the real complexity in the interface is about region-selection, and the operations are actually trivial. Of course, you need to first select regions (like interesting lines), then select other regions within those, others within those etc. How to chain it all in a natural way?
swah 12y ago
Mine is the pain of loving emacs and not using because of wrist pain.

lispm 12y 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 12y ago
Emacs also have M-h to mark the current paragraph, so M-h C-w will cut the current paragraph.
FatalBaboon 12y ago
i simply bound flush-lines for that
gkya 12y 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.
- lispm 12y 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.
  - groovy2shoes 12y ago
    Just out of curiousity, what is your favorite editor?

norswap 12y 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).

calibwam 12y 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.
- lispm 12y 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.
  - calibwam 12y ago
    On a macro level, I agree. But switching mode isn't so hard that you have to sit twenty minutes in normal mode, thinking what you would do in the entire document, before you switch to writing it.
    - mercer 12y ago

MichaelGG 12y 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/ http://vim-adventures.com/

anonymoushn 12y ago
VIM Adventures looks great! I'd love to buy it, but the author is only willing to rent it.
- MichaelGG 12y ago
  6 months at $25? Personally I feel I've gotten far more value out of it than that.

NAFV_P 12y 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 http://almy.us/teco.html

recraft 12y ago
Emacs was originally written as a series of TECO macros.
- kps 12y 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.)
lispm 12y ago
If you think Emacs is hard to grasp, try out vi.
- NAFV_P 12y 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?
  - goldfeld 12y ago
    If you're asking about ergonomics overall, I'd say Vim, definitely. Though a lot in both cases can be mitigated with useful remappings (use Caps Lock as Ctrl, or as Esc! Or as both! https://github.com/alols/xcape https://github.com/alols/xcape or KeyboardRemap4Macbook). Also I find Dvorak a lot more pleasant on my fingers than good ole QWERTY. I have at various different times felt a lot of strain hit some of my fingers, especially the pinkies. My right pinky complained first, and I realized how much it was used for. I first switched from Dvorak to Programmer Dvorak so that my pinky wouldn't have to do curly braces and square brackets anymore, and so that both those and parens no longer required a shift press (also helping the other pinky), since Programmer Dvorak switches numbers with symbols (the latter of which I use far more as a coder.) I also got used to Ctrl-H instead of Backspace and Ctrl-M instead of Enter, wherever I could. They didn't work in the editor's command mode, so I created mappings so that they would. The issues went away. More recently, more than a year after that, I started feeling my other pinky, the left one. I severely reduced my Tab usage and began using the Left Alt as a Left Ctrl more, so my pinky shares Ctrl usage (which was already on Caps Lock, but still..) with my thumb. Also worked. An ergonomic keyboard would also be a fine acquisition. By the way, trouble in the "ulnar nerve which emanates from the neck" leading to "mild muscle wastage" sounds quite sci-fi to me (not disbelieving, just thought it sounded rather exotic.)

ClashTheBunny 12y 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 12y 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 12y 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 12y 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.
mkozlows 12y 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 12y 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.

fulafel 12y 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!

csirac2 12y 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

vram22 12y 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 ...
- vram22 12y 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).
- vram22 12y ago
  Edit 2: Also, vim has a built-in sort command: http://vim.wikia.com/wiki/Sort_lines 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.
- csirac2 12y 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.

irremediable 12y 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 12y ago
There are already alternatives to VimL. You can use Python, Ruby, etc.
- thristian 12y 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 12y ago
I was wondering when this would pop up. Smh
- irremediable 12y ago
  What does "smh" mean?
  - ovechtrick 12y ago
    Shaking My Head

goldfeld 12y 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 12y 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 http://github.com/guns/vim-sexp
deleted 12y ago
[deleted]
jacques_chester 12y 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 http://www.cs.yale.edu/homes/perlis-alan/quotes.html

deleted 12y ago

[deleted]

deng 12y 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".

rbanffy 12y 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 12y 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-Emacs-Thesis.html https://www.gnu.org/software/guile/manual/html_node/The-Emac...
aidenn0 12y ago
I thought GNU emacs was written in C.
- deng 12y 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.

jv_dh 12y 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 12y ago
Dead on! This is the biggest reason to know vi period.

johnchristopher 12y ago

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

178 12y 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?

falcolas 12y 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 12y 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.
  - 178 12y ago
    I couldn't have said it better. Also, I have yet to see a more compelling example of clever composition in vim than "delete 3 lines" (which even I do when rarely using vim).
    - falcolas 12y ago
      How about correct everything inside these parenthesis/brackets? Or indent everything within these brackets? Or do a search/replace over only the next paragraph? Or Title Case everything up to the next colon/semicolon/quote? Read the contents of file <x> into my current buffer? Format everything within these two matching quotes? Every movement is composable with every action. There's a lot of movements, and a lot of actions. Delete three lines is the simplest possible command, but it's hardly the only one.

Symmetry 12y ago

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

Tyr42 12y ago
http://www.vim.org/scripts/script.php?script_id=1234 http://www.vim.org/scripts/script.php?script_id=1234 You can add a yank ring to vim.

teeray 12y 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 http://www.youtube.com/watch?v=dP1xVpMPn8M

wingerlang 12y ago
Interesting but I feel the constant switching between mouse and keyboard would get annoying really fast.
- aidenn0 12y 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.
  - kps 12y ago
    Which goes all the way back to the beginning: Englebart's NLS, which had a mouse on the right and a chord set on the left of the keyboard. (Go watch The Mother of All Demos if you've forgotten; I'll wait.) The Xerox Alto borrowed the chord/mouse pair; then the Xerox Star team found the chord set too hard for normal people to learn, and substituted dedicated function keys on the left of the keyboard, still designed to be paired with the mouse. (Incidentally, while we're talking editors, Star had a MOVE key instead of CUT and PASTE, because it was a user interface principle that there be no hidden state.)
  - judk 12y ago
    Yes but whe editing programs we are constantly alternating between insertion and manipulation every few seconds. Acme with keybindings for chord actions might be interesting

dagi3d 12y 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 12y ago
Ag [1] has served me very well if you haven't come across it. [1] https://github.com/rking/ag.vim https://github.com/rking/ag.vim
- pmoriarty 12y ago
  There are also plugins like ctrl-p: http://www.bestofvim.com/plugin/ctrl-p/ http://www.bestofvim.com/plugin/ctrl-p/

icantthinkofone 12y 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.

falcolas 12y 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".
- jqm 12y 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 12y 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 12y 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 12y 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.

SoftwareMaven 12y 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 12y 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_quas 12y ago
  Check out evil-mode in emacs. Its wonderful.
  - platz 12y ago
    I wasn't much a fan last time I tried it. If you know more than the very basic vim movements, you'll find they start conflicting with the emacs keybindings; and it's frustrating to remember which one does which. In emacs i just gave up and tried to learn vanilla emacs even though i am a vim user.

pmontra 12y 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 12y ago
evil mode comes pretty close
jqm 12y 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 12y 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 12y 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 12y ago
Yeah the article sort of ended abruptly.
mkozlows 12y 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 12y 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 http://www.gnu.org/fun/jokes/ed-msg.html
- vidarh 12y ago
  For the uninitiated: "Eight Megs And Constantly Swapping" This page has lots more: http://www.gnu.org/fun/jokes/gnuemacs.acro.exp.html http://www.gnu.org/fun/jokes/gnuemacs.acro.exp.html
- ibrahima 12y ago
  I think for a lot of hackers, being able to run from over a terminal/ssh is a critical "design" feature.
  - spopejoy 12y ago
    Arrgh. Emacs on the terminal is a joy, and is present on more servers than you think (dreamhost for instance). Having said that I default to 'vi foo.txt' on the command line and feel like vi competency is a core server skill ...

omershapira 12y 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.

goldfeld 12y 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?
- omershapira 12y 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.

pothibo 12y 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 12y ago
Then can online editors like cloud9 replace vim? They can easily connect to any server and provide same ui for server and desktop.
- pothibo 12y ago
  The comparison is indeed more relevant.
curun1r 12y 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.

pmoriarty 12y 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 http://www.emacswiki.org/emacs/Evil

alwillis 12y ago
Nope--it’s not the same: https://news.ycombinator.com/item?id=7828825 https://news.ycombinator.com/item?id=7828825.
- pmoriarty 12y 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 12y 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 12y 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.

protomyth 12y ago
Its part of Cocoa, search for ~/Library/KeyBindings/DefaultKeyBinding.dict for more information and how to alter the behavior.
- jaequery 12y ago
  It's part of unix/linux, they all have emacs keybindings as default
  - protomyth 12y ago
    MarcScott asked about Mac OS and the unix subsystem isn't the part on Mac OS that provided the emacs bindings for the apps.
  - ibrahima 12y ago
    You're probably thinking of readline[1] actually. At the least that's why bash supports emacs keybindings (though I am never sure if a feature is from the shell or the terminal emulator). I believe you can configure readline to have vim keybindings. [1] http://en.wikipedia.org/wiki/GNU_Readline http://en.wikipedia.org/wiki/GNU_Readline
huxley 12y 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 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-keybinding/ http://www.leancrew.com/all-this/2011/11/capitalization-keyb...

ulisesrmzroche 12y 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.

pmoriarty 12y ago
You don't have to abandon vim just because of pinky strain. You could just remap jj or jk to ESC.
- judk 12y 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"?
  - pmoriarty 12y ago
    Just type jk slowly. Also see [1]: :help timeoutlen and :help ttimeoutlen [1] - http://vimdoc.sourceforge.net/htmldoc/options.html#%27timeoutlen%27 http://vimdoc.sourceforge.net/htmldoc/options.html#%27timeou...
    - isbadawi 12y ago
      Alternatively, you can type jjkak (insert a j, exit insert mode with cursor on the j, enter insert mode one character to the right, insert a k).
  - Syssiphus 12y ago
    http://vim.wikia.com/wiki/Avoid_the_escape_key http://vim.wikia.com/wiki/Avoid_the_escape_key See the 'jj' part in the 'Mappings' section.
  - rbonvall 12y ago
    Just like in the shell, anything prepended with Control+V will be input literally, so you can type Dij<C-v>kstra.

emsy 12y 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 12y 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 12y 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 12y 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 12y 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 https://github.com/atom/atom-shell

colin_mccabe 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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 http://www.vim.org/scripts/index.php