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.
> 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.
Actually, you can have paredit-style structured editing for whatever languages you want to support. For example, there is a pretty capable structured editing mode for Haskell[1], which has a syntax significantly less regular than s-expressions. (On the other hand, it's still more regular than most languages...)
> There might as well be no concept of "words" or "lines" in a seasoned lisp programmer's mind, there's only sexps and forms. And it's so much easier to reason that way, which is not a fault of vi's grammar but arguably a fault of most programming languages' grammars. It's that fabled saying that you should rather have one data structure (sexps) with 100 operations on it than 10 structures (words, lines, bracketed expressions, paras) with 10 operations each.
This really can't be overstated.
Even if you don't really use Paredit or any kind of special tool S-expressions lend themselves to easy modification. Since a Lisp program is, by virtue of the structure, organized by default into easily separated components there is no need to think about anything else other than just expressions.
When I write Racket code (in Emacs), I organize and move code in expressions instead, and if I wanted to move a certain expression I would just move to the enclosing paren and hold shift while saying "move to matching paren" and the whole expression will be marked and I can do whatever I want with it.
I used to use vim before and while I did "get it" after a while I switched to Emacs when I started learning Lisp because I figured I could immerse myself in Lisp code with Emacs.
The thing about it is that since I've coded almost exclusively in Lisps since then I haven't really needed what vim does best. At some point a while ago there were a slew of posts about vim and I looked at maybe getting evil-mode for emacs, but I don't know if I see the point when I almost exclusively deal with sexps.
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".
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.
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.
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".
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.
I'm not really commenting on vim. I actually had a previous comment written where I said almost exactly what you said. I'm not even saying one is better than the other, just that the author's understanding of Emacs was, IMO, less than complete.
The funny thing is both vim and Emacs have these weird learning curves: Emacs starts easier (you can actually type something; wtf is a mode?!), then vim becomes easier (modes and command composing over finger gymnastics and pages-long key bindings), then (and this is, of course, my opinion) Emacs with its programmable everything starts to shine. I wonder how much of the editor wars are simply where people are along that continuum.
Agreed evil in emacs is very good. It is the best vim emulator I've ever used and is even better than vim in instances (like when it shows you everything you are replacing as you type the replace command).
Lately though, after near a decade of using vim, I've been trying to unlearn vim. Many editors provide easy ways to navigate, search and replace the way you do in vim 80% of the time without all the baggage that modes bring. The baggage that vim creates is muscle memory training to navigate with hjkl which is incompatible with non-vim input boxes. I'm also not a fan of the vim source code or its creator and it may be too late for me to care about neovim.
Another negative aspect of vim is that at least in myself and maybe in others it leads to an unearned increase level of engineering confidence as you master an arguably useless, esoteric skillset that doesn't translate into better understanding of basic computer science topics. Vim does help improve regular expression familiarity, but that may be it.
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.
That's precisely the parent's point. The Vim model (I'll exclude vi from the discussion since it lacks core aspects of Vim's composability like text objects, and almost no one should be using it) is about having a largely inflexible editing language built off of composability. The Emacs model is built around infinite extensibility instead. That's why implementing Emacs in Vim would be fundamentally at odds with the principle of Vim, but it's very possible to implement the Vim model in Emacs, and Evil does a nice job.
Well, there's vimacs (http://www.vim.org/scripts/script.php?script_id=300) which gives you the basic keybindings and modeless editing. I agree though that the vi modes for emacs give you more than the emacs mode for vi.
I started out in Emacs, used it and customized it for years. Then I decided to see what I was missing in Vim, so I switched entirely for two years. I became very comfortable with that world.
Then I spent about a year in the strange netherworld of viper-mode and vimacs, switching around more or less at random.
Eventually, I landed back in plain emacs for most things and have been there for the last ten years. I have nothing against vim and still use it from time to time, particularly when I'm working on a remote server. I just realized that for me, emacs was at least as capable on every front and seemed to suit my way of working better.
I’ll bring out the one of the more influential articles on Vim to further explain the author’s point—Your problem with Vim is that you don't grok vi: https://gist.github.com/nifl/1178878
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.
" The basic summary is
cursoring around required a
higher level of mental
planning to organize the
interaction, which apparently
obscures the perception of
the passage of time--think
of being deeply engaged in
something and being
surprised when you look at
a clock-- whereas the use of
the mouse was done at a
lower, mechanical level that
left the mind free for higher
things, such as complaining
about the mouse."
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.
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.)
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.
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?
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.
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.
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.
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.
The moment I read "I believe those interfaces are inferior", my mind started dumping half a dozen paragraphs of ranting, but that would be painful to write, so I'll just leave it at an analogy to try and make you see how you're the one being closed minded here:
That's a bit like a native Esperanto speaker saying "I don't know what's all the fuss about English being a lingua franca, I learned how to say hello and goodbye and I don't feel I can access all that wealth of knowledge people claim is available to them." Obviously they would have said that in Esperanto, but I don't know it.
"Mi ne scias kio estas tuta vanti angla estante pontolingvo, mi lernis kiel diri saluton kaj adiaŭo kaj mi ne sentas mi povas aliri ĉiujn kiuj riĉeco de scio personoj asertas disponeblas al ili."
Esperanto seems roughly as dense as english, maybe slightly less.
There was (probably still is, but I haven't been following for a couple decades) debate analogous to vi-vs-emacs among Esperantists, between word formation by composition and calquing (which fits the language's agglutinative core) vs word formation by borrowing.
That's a thoughtful post, and you shouldn't be afraid to say that something is inferior or superior (and "in my opinion" is assumed). My first programming experiences were on the Apple IIe, and it was much more similar to Windows than to vi or Emacs, and I don't believe my ability to edit files was particularly harmed by not using these editors.
Moreover, although I use vi on occasion (because it's ubiquitously installed and readily accessible in a terminal) I don't like it at all. It fails almost totally on the level of discoverability. That is, those wonderfully composable commands are impossible to discover in vi itself. It also fails at the level of giving good feedback about what you're doing right now. Finally, it fails because it's confusing because modal editing is confusing. It makes much more sense to me to use "out of band" input (like meta keys and mouse input) which is psychologically orthogonal to actually entering text. Not to mention the fact that in situations where you want to move and edit a lot, you actually add a LOT of keystrokes.
I agree that composability is a very cool feature of vi, but the negatives dominate this. (This is the reverse argument that people seem to ignore about javascript: the ubiquity and power of js absolutely dominates, by several orders of magnitude, it's weaknesses as a language and runtime.)
In any event, arguing about text editors truly is like religious argument: if you enjoy using emacs, vi, or notepad, I'm happy for you! In the end, if it works for you then it's good, and it seems rather counter-productive to try to convince people one way or another.
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.
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.
You don't get it. We don't necessarily want vim to live forever. We'd love for another editor to come along and eat vim's lunch. It's just that in order to do that it needs to take the lessons that vim has taught to heart.
I keep hoping a better Vim will come alone. KDE's Kate gets closer as its Vi bindings improve, but it's still a big enough uncanny valley that I can't switch over (and I'm a KDE dev!).
I understand this sentiment, but is there really a way to do this without simply recreating or emulating vim? I can't really think of a way to compose complex, precise actions ("delete the next 4 lines", "undo changes on this line") purely with mouse clicks or swipes like you can with keystrokes.
Every GUI text editor requires a combination of a cursor and keystrokes to accomplish things like this, and they probably will for a very long time.
A text editor that can replace vim would definitely be very much like vim, and it would probably be modal and have very similar if not the same command set. This would be no more a 'recreation' of vim than other text editors today would be recreations of each other just because they all come with very similar actions, commands, and features.
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.
(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.)
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!!!
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.
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.
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.
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.
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.
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?
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?
I want to delete a domain object (in the context of text, most objects are chars, words, sentences, paragraphs). So I tell the system delete ('d'), then what I want to delete, almost declarative (the what).
Emacs requires to explicitely tell him to create two pieces of data (begin and end marks) then ask for deletion (~the how).
Quantitatively it's also heavier, since it's a 2 keystrokes in vi, and 3 in emacs.
If you have used a Lisp Machine with something like Zmacs for an extended time, then one often manipulates with the mouse. Same sequence: mark, execute. For some things there is also modifier-click on something visual which creates a region.
Thus the whole select the object, execute sequence is the same:
* emacs keystrokes
* mouse manipulation
* Lisp functions: get the arguments, execute a function
Unfortunately I never had such pleasure. I understand a little more the appeal to have consistency between mouse and keyboard operations.
Maybe I'm more a schemer than a lisper then because even though the function call protocol is eval args, eval body, one of the nicest thing about lisps is higher order functions. Vi feels exactly like this; a move is an abstract operation that can live on its own, or be passed to another abstract operation to be combined.
To the extreme it reminds me of point-free programming where you dont even pass ~toplevel arguments, you just accumulate hof.
I've used all sorts of user interaction schemes, I don't think that's habit anymore.
It's an unnecessary explicit operative order. Like saying writing assembly code is just like C backwards, you'll get used to write callee saved arguments on the stack.
You can only say those are bound to different functions because they are visible to you. Are you sure Via, under the hood, is not the same? Also (can't check it right now), these lisp functions can all be calling the same mechanism with different parameters, being only declared separately for convenience.
To be honest I don't have the slightest idea about how vi does it, but it feels like the design is operations taking 'move' entity as argument.
I glanced a bit at the actual elisp, it's not trivial dispatch, it's multiline intertwined bits of logic.
And even then, to the user it doesn't matter, the composability is hidden from him, making learning longer and failing to expose a very valuable concept entirely.
Some very interesting software pushed the idea of composability to visual tools even, look at Luxology Modo, where you can merge small widgets/tools into the one you need. Very neat.
Yes, it is not the same under the hood. You can easily define new motions in vim (eg. I have a plugin in vim that adds “aa” (=an argument) - a motion that selects one argument in a function call. And all vim functions will work with that motion.
All of those function call kill-region, FWIW. The extra code defines which region and handles things like attempts to kill text that is wholly or partially read-only.
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).
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.
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.
Even though I'm a very 'mixed' type of writer/coder, I find normal mode very useful because moving around in the document, for me, is much faster that way.
So even if I only have to move x words to the left, delete until the first occurrence of character y, or change the text inside the very next quotation marks (one of my favorite tricks), the 'hassle' of switching between modes is worth the ease of moving around the document. In the few cases where I need to do something even more trivial, I can still navigate the 'regular' way in insert mode.
Furthermore, I find that I generally work better if I don't just rapidly and constantly switch (mental) modes, even for prose. I'm starting to feel my 'instant' connection to the output makes me sloppier and makes it harder for me to reason about what I'm exactly trying to do. So for me it even has a psychological benefit to use an editor that has modes.
It works out in practice that you have vi-like modes in emacs. When you hold control down you are in one mode and when you hold Meta down you are in another mode. The difference is state. In vi you have to remember which mode you are in. In emacs you know by which modifier you are holding down. The issue of compossabity is orthogonal.
For example in emacs you can move around, cut, paste, do minor manipulations like swapping words or case all while holding control down. When you want to enter text you let up.
For me, I was used to mainstream text editors that use modifier keys. I found vi difficult to get into, but I finally grokked it when I considered 'normal' mode to be affected by an imaginary key called 'ctrl-lock'. Like numlock and capslock, ctrl-lock keeps your modifier key 'held down'. It's not quite accurate, but it was the conceptual shift I needed to 'get it'. Also, you don't have to remember which mode you're in in modern vi clones, as they generally tell you in the status line. Not that you particularly need it, because when you're comfortable with any editor, you have a practiced set of moves that you don't have to think about.
Now I'm not a vim god, but I've used it enough that I have muscle memory that affects my use at the command line - I'll want to change something in a parenthesis and will type "ci(" (change inside parenthesis), only to find the literal characters appear... :)
Exactly. And since I recently mapped 'normal' mode to the Caps Lock key, it's even easier. I did this because I was forced to use a keyboard that had no ESC key, but it's been very useful with vim.
In vim, you can still move the cursor around when in insert mode. It just isn't that functional and after a while you realize it rather is a beginner's mistake. Anyway, those modes aren't totally separated from each other. There also are shortcuts to quickly do something in another mode.
Having used emacs and vim for several years, I now am in favour of vim's editing modes. The only thing I don't like about it is the column numbering at the first or last position of the line (a problem you become only aware of when developing plugins though).
So in some sense there are two major features of vim, one being the composable commands, and the other being the modal editing. They seem to not necessarily be related, for example there's this thing called 'god-mode'[1] for emacs which is kind of like vim's normal mode, and control becomes implicit. I haven't gotten a chance to really adapt to using it but it seems like it could bring a lot of the benefit of vim's shorter syntax to emacs users without requiring us to change our muscle memory with regards to the key sequences.
The region thing (along with vim modes) is probably one of the biggest pieces of pushback I've gotten from the piece, and I think it certainly has some merit to it. If you can use movement commands to define a region, and then act on that region, isn't that the same as vim's composability in effect?
I think the best answer is "sorta, but not really."
The biggest reason why is that Emacs commands don't all work on a region by default. Yes, there's C-w to kill-region, but there's still C-k to kill-line and other special-purpose commands out there. In Vim, there aren't four special-purpose delete commands and then a general-purpose one, they all work the same way. This feels like a qualitative difference to me -- both in theory, and in practice.
When I used Emacs for many years, I definitely did use the region commands, but only when the special purpose ones wouldn't work reasonably (like deleting large chunks of code). If I just wanted to delete (for instance) the stuff inside an HTML tag, I wouldn't try to mark off a region and then delete it, I'd just delete by word/character until it was gone. In Vim, I'd "dt>" automatically, because that just makes a lot more sense than repeatedly typing "dw".
And ironically, Emacs has a command (M-z is the mapping for kill-to-character) that would do exactly the same as that Vim command. But in fourteen years of Emacsing, I never even looked for it, because Emacs doesn't steer you that way. Vim makes you always think about what object you're applying your command to, and because you always have to make a choice, you look for good choices; Emacs generally defaults you to one of a few often-decent choices, and you don't get into general-purpose mode unless the built-ins are unworkable.
> The post also fails the mention the concept of region in Emacs: you select a region than perform one (or multiple) commands on it, instead of encoding the region in the command like in vi.
Would the visual mode selected areas in vim be equivalent to this?
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.
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.
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.
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.
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.
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.
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
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:
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.
, 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.
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).
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.
It comes from NeXTSTEP, text fields were given several emacs compatible keystroke editing commands as part of the key bindings for NSTextField and NSTextView.
You can modify the default keybindings and even add more emacs compatible keystrokes if you find it helpful and most Cocoa apps will inherit the new keystrokes: http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html
(it's a good article that also has some interesting info on Input Managers and modifying keyboard layouts)
drdrang wrote an article that linked to several other good sources on the subject:
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.
"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.
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/
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?".
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.
> 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..)
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.)
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.
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.
I use a lot of GNU Emacs and I think it is the best editor for a lot of purposes. There is a lot to admire. For example the many very sophisticated and well written contributions.
At the same time I, as a Lisp expert, don't like the technical base of GNU Emacs. Single threaded, poor Lisp dialect, just now support for lexical binding, not object-oriented, ugly UI, complex key bindings, ...
For editing Lisp code I prefer to use the LispWorks editor. It is also an Emacs, but written in Common Lisp and based on the Hemlock Emacs of CMU. But this does not have the capabilities of GNU Emacs outside of Lisp coding.
From a usability and coolness view, Zmacs is still way ahead. But no longer practical - unless one could use it for some extensive Lisp project, which would justify its use.
Thus, I have no overall favorite editor. GNU Emacs is great, but it has too many and very diverse problems. I use it, but not without frustration.
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.)
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.
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.
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).
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.
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
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.
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.
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
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?
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".
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.
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).
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.
You can always just select stuff with your mouse and press the delete key. We're writing code, not prose, here. When was the last time you used paragraphs anyway?
Replace "paragraph" with "surround" (vim-surround), "argument" (argtextobj) or "indent" (vim-indent-object) then, which compose brilliantly with (c)hange/(d)elete + count + (i)nside/(a)round.
When writing documentation. The mouse + delete is not as easy when you're doing non-trivial movements, such as "replace everything between these matching parenthesis"
... 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
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?
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?
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.
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.)
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 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.)
Thank you for the github link, I'm looking at it now.
"ulnar nerve which emanates from the neck" - I should have said "my left ulnar nerve is pinched or aggravated in the neck", that's more accurate.
EDIT:
I have pondered this before, using speech to text software, the muscles in your face and jaw have relatively good stamina. But it might be a bit of a tongue twister trying to 'speak' C. From my experience most programming languages are like Latin, easier to read than listen to.
Have you considered getting a set of keyboard pedals, so that modal keys -- ctrl, alt, esc, etc, can be mapped there, leaving your hands open? Also, have you talked to your doctor about exercises -- using resistive elastic bands, etc, to help restrengthen your muscles?
If you get trouble using a mouse, Emacs/Vi are better than IDEs. If you have general troubles with keyboards, IDEs are better.
Emacs has imho superior functionality. But if your neck gives you problem with the "chording" you use in Emacs (lots of cases with multiple keys pressed down at once), then Vi's modes would be helpful. [Edit: goldfeld's comments re keyboards are spot on. I have some early neck troubles, I might have to go that way too. The doctors tell me it is common in our profession, we sit still too many hours.]
Anyway, Emacs is really optimized for editing, not for learning to edit. I still recommend the trip.
An anecdote about the last paragraph:
I read online that Org Mode was the best thing since sliced bread. So I sat down and spent lots of hours to learn it. Afterwards, I thought -- "wtf did I just do?! I could get > 50% of that functionality from a web/iPad app I would learn in ten minutes?! Was that really worth the time?" Then I realised that I can write/edit Org modes lists almost as good as todo lists on paper; it was so far down in the brain stem it took no attention from what I was writing.
>if your neck gives you problem with the "chording" you use in Emacs (lots of cases with multiple keys pressed down at once), then Vi's modes would be helpful.
If the goal is to eliminate the need to hold down a key while pressing another key, turning on "sticky keys" would a lot easier than adapting to a different text editor.
"Sticky keys" is available as an option (usually accessed via Settings > Accessibility) in OS X, Gnome 2, the Linux console, Windows and probably other environments (though ISTR some bugginess in how it worked in Windows the one time I test-drove it in Windows).
Source: I have been using sticky keys with Emacs (on OS X, Gnome 2 and the Linux console) for the last 15 years or so.
"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.
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".
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.
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.