
Why Atom Can’t Replace Vim – Learning the lesson of vi - jpace121
https://medium.com/programming-ideas-tutorial-and-experience/433852f4b4d1
======
goldfeld
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
> 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)

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

~~~
aidenn0
I thought GNU emacs was written in C.

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

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

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

------
SoftwareMaven
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
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
Check out evil-mode in emacs. Its wonderful.

~~~
leorocky
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.

~~~
platz
Main thing for me is most new languages have a large userbase in vim (as well
as emacs).

So for example, Clojure has vim-fireplace for an excellent clojure experience.
Same thing with Haskell.

Go to where the users are and your life will be easier.

~~~
joelthelion
Could you describe your Haskell+vim experience a bit more? Do you have smart
autocompletion? How well does it work?

~~~
platz
Check out
[http://haskelllive.com/environment.html](http://haskelllive.com/environment.html)

I don't use Syntastic, but haskellmode-vim and ghcmod-vim integrate nicely
with ghci, and neco-ghc gives autocompletion.

I don't use tags files or other project-level stuff, the above is good enough
to get started.

Also once you have ghcmod-vim you can map a key to tell you the type of an
expression:

    
    
        au FileType haskell nnoremap <buffer> <F12> :GhcModType<CR>
    

It does take some work to get all these things installed, however.

------
teeray
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
Interesting but I feel the constant switching between mouse and keyboard would
get annoying really fast.

~~~
aidenn0
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
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.)

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

------
Monkeyget
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
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.

------
ilaksh
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.

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

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

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

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

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

~~~
kps
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.

------
octref
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.

~~~
mkozlows
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.)

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

~~~
spopejoy
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 ...

~~~
z0r
If you haven't used TRAMP to view and edit files on other servers from your
local emacs session, you should give it a try.

~~~
spopejoy
TRAMP's nifty, but it used to lock up emacs on shaky connections. Maybe it's
better now?

------
colin_mccabe
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
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.

------
reuven
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
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
Emacs.

c-w will kill the active region.

~~~
agumonkey
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
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.

~~~
agumonkey
It seems backward to me.

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.

~~~
lispm
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

Thus it is a very consistent model.

~~~
agumonkey
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.

------
norswap
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
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
> 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
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
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.

~~~
vacri
For me, the 'hassle' of moving between normal and edit mode in vi is far
better than having to use a modifier key for every single command.

~~~
onedognight
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.

~~~
vacri
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... :)

------
bhuga
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.

------
nathansobo
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
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
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.

------
csirac2
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
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 ...

~~~
csirac2
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.

~~~
vram22
>Vim is one of the few tools that keeps rewarding me more and more, the longer
I use it.

True :-)

------
MarcScott
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
Its part of Cocoa, search for ~/Library/KeyBindings/DefaultKeyBinding.dict for
more information and how to alter the behavior.

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

~~~
ibrahima
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)

------
irremediable
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
There are already alternatives to VimL. You can use Python, Ruby, etc.

~~~
thristian
"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.

------
MichaelGG
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
VIM Adventures looks great! I'd love to buy it, but the author is only willing
to rent it.

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

------
ClashTheBunny
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?".

------
myspy
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
> 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..)

------
lispm
> 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.

~~~
gkya
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
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
Just out of curiousity, what is your favorite editor?

~~~
lispm
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.

~~~
groovy2shoes
I wasn't expecting such a detailed answer. Thanks!

------
jrockway
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.

------
pmontra
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.

~~~
jqm
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.

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

------
pmoriarty
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
Nope--it’s not the same:
[https://news.ycombinator.com/item?id=7828825](https://news.ycombinator.com/item?id=7828825).

~~~
pmoriarty
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.

------
jakejake
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)

------
pothibo
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
Then can online editors like cloud9 replace vim? They can easily connect to
any server and provide same ui for server and desktop.

~~~
pothibo
The comparison is indeed more relevant.

------
fulafel
) 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!

------
dagi3d
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
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
There are also plugins like ctrl-p:

[http://www.bestofvim.com/plugin/ctrl-p/](http://www.bestofvim.com/plugin/ctrl-p/)

------
178
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
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".

~~~
ulisesrmzroche
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?

~~~
lloeki
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.

------
MichaelMoser123
... 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)

------
pjungwir
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
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?

------
ulisesrmzroche
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
You don't have to abandon vim just because of pinky strain.

You could just remap jj or jk to ESC.

~~~
judk
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
Just type jk slowly.

Also see [1]:

    
    
      :help timeoutlen
    

and

    
    
      :help ttimeoutlen
    

[1] -
[http://vimdoc.sourceforge.net/htmldoc/options.html#%27timeou...](http://vimdoc.sourceforge.net/htmldoc/options.html#%27timeoutlen%27)

~~~
isbadawi
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).

------
emsy
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.

------
NAFV_P
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
Emacs was originally written as a series of TECO macros.

~~~
kps
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, «i _text_ ESC» 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.)

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

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

~~~
Tyr42
[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.

------
icantthinkofone
"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
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
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.

