
Editors (Vim) - Austin_Conlon
https://missing.csail.mit.edu/2020/editors/
======
ljosifov
This (advanced?) vi/m tutorial I really liked and found it useful over the
years [https://www.ele.uri.edu/faculty/vetter/Other-
stuff/vi/009-in...](https://www.ele.uri.edu/faculty/vetter/Other-
stuff/vi/009-index.html). It is by Walter Alan Zintz, originally published in
UnixWorld Online, dvelves into more advanced vi/m use. From
[https://sanctum.geek.nz/arabesque/unidex/](https://sanctum.geek.nz/arabesque/unidex/),
that itself I find a gem (e.g [https://sanctum.geek.nz/arabesque/series/unix-
as-ide/](https://sanctum.geek.nz/arabesque/series/unix-as-ide/)). Long time
lurker first time poster, registered for this :-O

------
hwestiii
I feel about Vim the way RMS seems to feel about Linux. Even though,
(presumably) everyone knows the relationship of vim to vi, I don’t feel there
is enough explicit acknowledgement of that fact. Vim is evidently a wonderful
tool, (I say this as a confirmed 20 year emacs user for whom emacs is only
usable due to excellent vi emulation possibilities) but it clearly wouldn’t
exist without the basic foundation provided by canonical vi which is in my
estimation a work of genius.

~~~
erklik
I use vim regularly on my day job. However, I am not familiar with more of the
advanced side of things, and would never call myself an advanced user. That
aside, I was always of the impression that vim was simply vi but extended in a
sense.

Is that not the case? How different is vi to vim?

~~~
aoloe
In my eyes, vi is ok for system administration, but not for programming.

The differences are not huge, but even if I have a "small" .vimrc with one
single plugin, I have issues using the vim.tiny installed on Debian by
default.

The Vim help has a list of the differences:

[https://vimhelp.org/vim_faq.txt.html#faq-1.4](https://vimhelp.org/vim_faq.txt.html#faq-1.4)

The most important to me are:

\- a real undo \- buffers \- macros (recorded on the fly with ththe q key) \-
visual mode (included the block selection mode) \- text completion (ctrl-p,
ctrl-x-f) \- automatic indenting \- advanced text objects (selecting everyting
between '()')

Not having one single of them would not hinder me much... but all of them at
once: that hurts!

~~~
mmm_grayons
The "killer feature" for me is asynchronous jobs. It makes life so much
easier.

------
ima_banana
Has eye-tracking been explored for improved code editing beyond Vim?

Vim does away with the hand-travel delays, but many of these ninja keystroke
moves to navigate code are just what your eyes do already (but not all, such
as the search function).

~~~
jamesrcole
Looks like it has. E.g.

\- [https://medium.com/fast-company/the-mouse-of-the-future-
your...](https://medium.com/fast-company/the-mouse-of-the-future-your-
eyeballs-dd728cc7e111)

\-
[https://purehost.bath.ac.uk/ws/portalfiles/portal/190368020/...](https://purehost.bath.ac.uk/ws/portalfiles/portal/190368020/ReType_CHI2019.pdf)

more
[https://www.google.com/search?q=eye+tracking+text+editing&oq...](https://www.google.com/search?q=eye+tracking+text+editing&oq=eye+tracking)

~~~
airstrike
Was going to read the first link, but can't be bothered to sign up / sign in
to medium.com. Screw that platform.

------
michaericalribo
Vim is a well-sharpened pocket knife, a precision tool that excels at editing
text interactively.

It’s interesting to me the different models for tools that address similar
problems. I used to use vim, and the chords of keystrokes are still fresh in
my mind, even though I switched to emacs years ago.

And now I use vanilla emacs —but that model is totally different, it’s an okay
text editor but an excellent customizable user shell. It’s not a matter of
better//worse, but of different philosophical approaches

~~~
Cyph0n
When deciding between whether to learn Vim or Emacs, Vim won me over with
three things:

1) Learning Vim increased my efficiency across multiple machines, and not just
my dev machine.

2) It's extremely lightweight. Note: you still need to be careful with
plugins!

3) Modal editing is easier on the wrists. Most of my time as a developer is
spent navigating through code (whether editing or browsing), and Vim's normal
mode keybindings are much less modifier-based.

------
pixelmonkey
I've been a happy vim user for many years, over a decade. But I was shocked at
how this talk, published on YouTube in 2018 from a recorded lecture by an
engineer at Yelp named Leeren Chang, basically made vim’s internal model
“click” for me and made vim even more fun to use. I really feel the presenter
did such a great job showcasing vim ideas — conceptually, visually, and by
direct example — that, by the end, I downloaded the talk into my “great tech
talks” stash and labeled it, “vim’s missing manual.”

Here it is: [https://youtu.be/E-ZbrtoSuzw](https://youtu.be/E-ZbrtoSuzw)

~~~
s3graham
Heh, "how you access ex commands shipped with Unix since like the 90s"

------
ilaksh
I have been using vim as an advanced beginner off and on for more than 15
years I think.

I use it lots of times (not for everything, I also use Visual Studio Code),
mainly because it means that I can just ssh over to a VPS and edit a file in
there, without having to set up fuse or some other way to edit locally. It
seems like less work to just get into files and set up a new VPS. And I know
there will be syntax highlighting for everything.

And also I have kind of a sunk cost of finally learning how to do basic things
over the course of many years.

But personally, I think that it is embarrassing for people who seriously
espouse that modal editing is better than more modern concepts. The reason we
have hjkl for movement is because that is what the terminal was like when vi
was invented. And the reason its Escape which is a little inconvenient on
modern keyboards is because the Escape key on that terminal was more like
where Tab is. And the reason its modal editing is because "real time editing"
didn't even generally exist when vi was invented:

"Back in 1970s, terminal screen are 80 columns by 24 lines. There's no real-
time editing. You edit by typing a command, then call another command to have
the screen update to show the result of your command. Vi's “modal editing” is
evolved from this."
[http://xahlee.info/kbd/keyboard_hardware_and_key_choices.htm...](http://xahlee.info/kbd/keyboard_hardware_and_key_choices.html)

------
vulcan01
I feel like it would be far more useful to just talk about _vimtutor_. At
least for me, it was the only way I was able to grok vim.

~~~
ryannevius
This. And if you get to the end of vimtutor, you'll see a recommendation to
continue learning via `:help user-manual`. I would have saved myself months of
effort trying to learn Vim if I would have just RTFM.

------
partiallypro
I'm by no means a high level expert of command line, but if I need to do a
quick edit I just use nano, and if I need to get down and dirty I use VS Code.
Is this abnormal? I know a lot of power users use Vim, but I've just never
fallen in love with it.

~~~
archarios
This is unfortunately not uncommon. I feel like most of my coworkers at most
companies Ive worked for don't use vim. One killer app of vim for me is
macros. You can record a string of commands and map doing that to a letter.
This makes certain mundane changes you have to do sometimes in software a
breeze. For example, I had some code where someone was using string literals
everywhere when they should have defined an enum. The convention we use for
this kind of thing is to use UPPER_SNAKE_CASE and the strings were in
camelCase. I was able to define two macros that let me improve this code in a
few seconds. If I wasn't using vim I'd probably just leave that code as it was
because it would have been so much effort.

~~~
j-james
> If I wasn't using vim I'd probably just leave that code as it was because it
> would have been so much effort.

Most modern editors, Visual Studio Code included, have powerful refactoring
abilities. Not only that, but they're usable without needing to be an editor
expert - just right-clicking and selecting "Change all occurrences" (or
pressing F2) does the trick.

~~~
read_if_gay_
This is reasonably fast, but not nearly as fast as if can be on Vim. IDK how
GP did it, but one quick way might be searching for strings and hitting .
whenever the macro needs to be applied. So you would end up doing something
like n n n . n n . n n and so on, where each n means “go to next string” and
each dot corresponds to finding and renaming something manually in other
editors. You can go through dozens of occurrences in seconds, orders of
magnitude faster than other editors.

~~~
allannienhuis
The vscode rename is much simpler/faster than that - cursor over the
symbol/variable, press F2, type in the new name, press enter. Renames all
references across all files in your project.

edit: no shade on VIM and VIM macros; they're great. I'm a very experienced
vim power user, but have switched to vscode with vim keybindings, and I'm very
very happy with the switch.

~~~
read_if_gay_
This is true for renaming a variable but GP mentioned converting string
literals to enums. For tasks like that, I think Vim is pretty much the
fastest. Also, Vim can also rename variables with coc
([https://github.com/neoclide/coc.nvim](https://github.com/neoclide/coc.nvim))

------
moonchild
> no matter what shell you use, you can export EDITOR=vim

Nit: in csh, it's 'setenv EDITOR vim'

------
srameshc
Researched a bit for last few days about IDE and Vim seems to be the only
viable long term option. I like Atom but it crashes all the time, VSCode
doesn't feel clean to me. IntelliJ is the best but expensive. Only option I
think is vim or Emacs. I loved the time I spent with Emacs last time, but gave
up quick. I will learn to use Vim this time.

~~~
bcrosby95
Or both! I was a long time Vim user that switched to Emacs with evil mode.
Using spacemacs.

I have a couple friends that swear by Sublime Text. It costs money but its not
terribly expensive, and super fast. Its vim plugin is a bit lacking though so
it wasn't that usable for me.

------
BooneJS
20 years ago I got a job and went from Windows to Unix. Tinkered with both
emacs and vim, and for some reason had this craziness where I'd start new
files in emacs and make small edits in vi/vim. I have dabbled with neovim and
vim-modes in other editors, but I keep going back to a somewhat-customized vim
with ~8 packages.

I'm not really an advanced vim user. I have to think and remember how to do
column edits, and I never yank to registers. For some reason I want to make a
concerted effort to learn emacs again but the idea of not having edit modes
concerns me.

~~~
mikekchar
Evil mode in Emacs is almost perfect. My biggest complaint is that undo works
differently than vim (if anyone knows how to fix that, I would be forever
grateful!) I originally used Emacs for about 20 years and then switched to Vim
for a variety of reasons. I love the editing model in Vim. But for the last
few years I've been using Emacs with Evil and it's been the best of both
worlds.

~~~
webgoat
Here you go: (setq evil-want-fine-undo t)

~~~
mikekchar
You are my hero!!!!

------
smitty1e
If you like modal editing, consider
[https://www.spacemacs.org/](https://www.spacemacs.org/)

The org-mode[1] outlining and magit[2] wrapper for git are most worthy.

[1] [https://orgmode.org/](https://orgmode.org/)

[2] [https://magit.vc/](https://magit.vc/)

~~~
cycomanic
I used spacemacs for a while, but once you use several layers it becomes so
slow that it makes VSCode feel snappy.

I also find that because it has such a customized way of doing things it often
becomes quite difficult to make your own customizations, especially if you try
to follow guides written for pure emacs.

I've just started using doom emacs, another "distribution" around evil-mode.
So far I really like it, it is much snappier than spacemacs and the layering
and customization system is much closer to traditional emacs.

~~~
smitty1e
I'm one of those for whom the 'space' in spacemacs is essential.

The regular key chords tore me up badly.

The performance/layers have never given me grief with spacemacs.

~~~
cycomanic
I agree, fortunately Doom uses the same type of keybindings as spacemacs

------
semicolonandson
If anyone is looking for some vim-porn (in the form of screencasts of a
decade-long user going through various workflows), I'd like to use this
opportunity to share some screencasts I recorded that I think will resonate
with fellow HN readers:

[https://www.youtube.com/watch?v=futay9NjOac](https://www.youtube.com/watch?v=futay9NjOac)

------
ulisesrmzroche
The best part about vim is modal editing and the key-command interface. Other
than that, it’s pretty much the same as everything else, worse, cus vimscript
is an abomination.

Best setup is vscode with vim emulation and I’ve been using vim profesionally
almost 15 years now.

Funny enough, I actually liked writing prose with Vim but I’m using Ulysses as
an editor for writing prose now

------
gorgoiler
I’m so used to vim as a code editor that I assumed, after the introduction,
this article was going to be castigating me for trying to write prose in vim
(which I indeed try to do on a regular basis, with what feels like a lot of
friction.)

Perhaps, as they imply, I should dust off a copy of Microsoft Word and switch
back to that!

~~~
blt
There is no conflict if you use LaTeX :)

~~~
gorgoiler
Goyo.vim was pretty helpful. So was formatoptions +a.

(The typesetting part isn’t the issue. Concentration and ease of flow in the
editor feel hard in vim, and LaTeX wouldn’t fix that.)

------
adamredwoods
I respect Vim, I've seen it used with impressive speed, BUT I am so used to
command-s to save, that I don't feel ready to :w enter all the time. VS Code
is powerful, and learning the keyboard shortcuts for that are getting better
every day (command-shift-p format-selection enter).

~~~
Ingon
You can put something like this in your .vimrc:

    
    
      " save with ctrl+s
      nmap <c-s> :w<CR>
      imap <c-s> <Esc>:w<CR>a
    

Edit: I guess it should be:

    
    
      nmap <D-s> :w<CR>
      imap <D-s> <Esc>:w<CR>a

~~~
kdheepak
You can also use

    
    
        imap <C-s> <C-o>:w<CR>
    
    

<C-o> in insert mode can be used to execute normal mode commands.

------
apotatopot
do set -o vi in bash and watch all your dreams come true.

~~~
archarios
I discovered this last year and it has made me so happy

------
ufo
I love vim but I always get a feeling that I'm only using 1% of its features.
It is hard to memorize all the availanle keybindings, specially if it is
something that you don't use often.

Does anyone have suggestions of what worked to help learn mor Vim commands?

~~~
codyb
I spend a lot of time in tmux and I frequently open and close terminal
sessions so I made this

[https://github.com/cboppert/motd](https://github.com/cboppert/motd)

It’s message of the day but with ViM tips. It worked fantastically for getting
small tips throughout my day that allowed me to consume and learn without
necessarily dedicating any tangible amount of time to it.

~~~
ufo
I love this idea! Basically a vim version of "fortune". Did you compile that
list yourself?

~~~
codyb
I think I took them from a big ViM cheatsheet somewhere.

------
caymanjim
If you think Vim emulation is a replacement for Vim, either you don't know Vim
or you don't like Vim. VSCode Vim emulation? Spacemacs? They are miniscule,
pale comparisons. VSCode is a fine editor. Emacs is a fine editor. Spacemacs
is pretty fantastic. But if you you think that's Vim, you simply don't know
and appreciate Vim. That's ok, but it's not even in the same universe as the
real thing. By all means use what you want, but don't try to sell it as close
enough.

~~~
gnl
Would you care to elaborate and point to some specific features and workflows
that you consider to be unique to the real Vim?

------
smabie
I would have expected MIT to rep Emacs, not vim...

~~~
SllX
Intellectual diversity lends itself to a diversity of editors as well.

------
jedwards1211
Vim emulation in VSCode worse than any other IDE I've used.

All extensions have to run on the same thread in a background process and
intercepted keystrokes are passed to that process over IPC. So if other
extensions (like the TS language tools) are tying up the extension host
process, the Vim extension can't respond to your keyboard input until other
extensions yield.

Performance issues come and go but for awhile I was stuck waiting for several
seconds any time I typed a < after an identifier.

A lot of us have tried to demand a separate process for extensions that
intercept keystrokes to solve this issue permanently. But the maintainers
don't really care.

~~~
chongli
As a long time vim user, I’ve tried VSCode a few times and I cannot for the
life of me figure out what all the hype is about. Can anyone who is proficient
with it explain the philosophy behind it and what makes it so great? This is a
sincere question, not a rhetorical one.

~~~
pvg
It's Emacs for Javascript people - a good thing since Emacs is moribund and
most programmers are at least a little bit Javascript people. A highly
programmable, cross-platform editor with zillions of extensions/modes that
support all sorts of languages and environments. People complain about its
resource requirements and performance, just like they did with Emacs. Vi(m)
users are the natural enemy of VSCode, just like they were the natural enemy
of Emacs, continuing their long proud tradition of being wrong about
everything. I think that's roughly where it fits 'philosophically'.

~~~
yjftsjthsd-h
I'm going to _partially_ disagree.

> It's Emacs for Javascript people

I'll accept this premise.

> a good thing since Emacs is moribund

And here we part ways.

> and most programmers are at least a little bit Javascript people.

You might be living in a bubble.

> A highly programmable, cross-platform editor with zillions of
> extensions/modes that support all sorts of languages and environments.

Agreed; I think you're actually underselling how helpful it is that it's
apparently a lot easier to get started with than emacs or the vi family. Power
tools with a lower learning curve is a good thing.

> People complain about its resource requirements and performance, just like
> they did with Emacs.

And they're right to do so, especially with Moore's law wearing thin. Besides
which, emacs (and n/vim, for that matter) are still around, and are just as
functional in a much smaller resource footprint.

> Vi(m) users are the natural enemy of VSCode, just like they were the natural
> enemy of Emacs, continuing their long proud tradition of being wrong about
> everything.

LOL, that's... semi-fair, even if you're on the wrong side, of course;)

> I think that's roughly where it fits 'philosophically'.

I think it's fair to call VSCode "EMACS but with JS", but I think you're
really glossing over the issues that it has in practice; maybe with a decade
of maturation it'll be on par, but today I would argue that it _is_ a resource
hog, and still suffers from some poor design choices (such as letting
extensions trample eachother, per the upthread discussion).

~~~
bitwize
It's not really.

The difference between VSCode and Emacs is the difference between an
extensible editor and a software omnitool intended to be extended, shaped, and
refined _as you work with it_. Writing short programs in Emacs Lisp, seeing
their effects _immediately_ in the live editor environment, and then (should
they prove generally useful) refining them into full-fledged modes or commands
is quite a bit different than writing a packaged extension.

There is, still, _nothing_ like Emacs in the editor world today. As much as
Visual Studio Code gets right, it has a long way to go to get within spitting
distance of Emacs in terms of adaptability and power (to say nothing of
resource consumption).

