How to Exit Vim | Hacker News Reader

How to Exit Vim

github.com

1,111 pointsjustinzollars395 comments

I first gained access to a UNIXish system in the fall of 1988, which was some SunOS4.x variant I believe. The shell was csh, the editor was vi, and I had no idea what I was doing, nor was there any help in my immediate area to be found. And no, I didn't know about 'man' yet.

Somehow I discovered that 'vi' was the way to edit things, but I didn't know how to exit, so trial and error led me to pressing control and z at the same time. Bingo! The shell is back.

After some days of building up background suspended vi instances, the system administrator came in and gave me a few pointers.

Did you save any?

Yes, I was able to save the file using ZZ rather than :w

It's been a long time, but I was probably hung up on not being able to experimentally figure out : commands, where I was able to figure out control-z and ZZ.

ZZ exits vi(m) though?

Yes, it sure does! Well, after 30 years, my memory of the particulars is a bit hazy. (:

Similar experience, except a ATT 3B2 (and thus no job control). I would have read the man page, but there were none, nor were any books available.

I finally just pulled the plug out of the wall.

It's not much of an exaggeration to say that I became a lifelong emacs user because the start screen even back then explained how to exit.

Holy shit, ATT 3B2, I haven't heard any mention of those in a long time.

So, six years later, in 1994, I found myself as the UNIX system administrator for a large (at the time) datacenter at Keesler Regional Medical Center, Keesler AFB, Biloxi Mississippi, where we had quite a number of 3B2s. They were, in fact, the only machines we had that were rated for classified data.

If memory serves, they ran AT&T System V release 3 UNIX.

We also had, among others, DGUX, SCO, AOS/VS, Sun and Vax/VMS servers. Of course each of AOS/VS and VMS had their own, non-UNIX operating systems.

Funny story: we put word out to AETC (Air Education and Training Command) that we needed more 3B2s, and a few months later, some pallets arrived from Homestead Air Force Base, which had been destroyed by hurricane Andrew a couple of years prior. These servers had green and brown smears on them. Clearly they had been submerged by hurricane flooding for some period of time. So we ran a long extension cord out to the parking lot, plugged them in and stepped back. Much to our surprise, several of them actually worked, and later ended up racked in our datacenter.

Ha. I miss the days when you didn't have to worry about your Unix box blowing away in a hurricane.

For what it's worth, I also used DG/UX, MV/UX and AOS/VS on Data General equipment (MV/10000, MV/4000) at the University of Washington in the 1985ish time-frame.

I remember porting many BSD 4.x utilities to MV/UX. What a learning experience, with the MVs differently-formatted byte vs. word pointers.

The C compiler was really nice, though.

Fun times.

You might be the first person I've run into that has heard of AOS/VS. I've run into one other person over the years that has heard of DG/UX.

Good times indeed.

My first Unix experience (~1993) was in a heterogeneous shop doing electronic pre-presss.

SunOS 3.5 on OEM PDP-11s. SunOS4.1.4 on SPARC Stations. SunOS5 (Solaris) on SPARC Stations. DG/UX on a pizza box. SCO on (I think) a 386

> ATT 3B2

There are a number of papers in pure mathematics authored by Doron Zeilberger and Shalosh B Ekhad. (See https://sites.math.rutgers.edu/~zeilberg/ekhad/papers.html for a list. I don't think it's exhaustive)

Shalosh B Ekhad is Zeilberger's computer, which once upon a time was an AT&T 3B1.

In Hebrew, 3 is "shalosh" and 1 is "ekhad".

(The 3B1 isn't actually much like the 3B2, despite the very similar names.)

I'm an emacs user to this day solely because it told me how to use it when I first opened it.

Wait really? I'm a lifelong emacs user too[0] but it only tells you how to exit if you open it without a filepath. If you're in a file because EDITOR was set to emacs by some other person and you try to exit it just says "C-c" or "C-c C-c is undefined" when it should just tell you how to exit. Or even better why doesn't it just exit on "C-c C-c"?

[0] Well I might write my own emacs-inspired, ruby enabled editor one day, but that's another story.

That's true. If you tried Control-H, you'd get a lead. Unless of course that was mapped to your main backspace key, which sometime happened in the bad old days.

As to why Control-C doesn't just exit the editor, I suppose it was generally considered to be a bad idea. And in the case of emacs, it might take five or ten minutes to restart. :-)

(It's worth noting also that GNU emacs ran on many platforms, some of which for which Control-C was not any kind of "kill my process" character.)

How careless of him, you obviously wouldn't have been the type to free them when you were done ;)

In the opposing vein, as an Emacs user the best configuration I ever made was to rebind C-x C-c to execute-extended-command instead of kill-emacs. It was way too easy to (even accidentally!) kill emacs with a sweep of a finger. And I probably use a few hundred execute-extended-command calls for each kill-emacs (which I now have to type manually as 'C-x C-c kill-emacs' - no problemo).

A similar optimisation was with tmux to bind the prefix to C-z. It's in a handy location next to ctrl and I very rarely use suspend anyway (which is still available as easily as C-z z). Stretching your fingers between ctrl and b (the default prefix key) merely made me wonder who the heck thought of something like this?

As for vi, I made a point of learning to use it enough to do useful work editing config files and small texts. Every once in a while another application brought up 'vi' for some reason (maybe I lost VISUAL or EDITOR while sudoing or the app was looking for another variable) and I could never exit the damn thing.

So instead of just learning :q and figuring out how to make the particular program or script relaunch another editor I thought it's the path of least resistance to just edit with vi directly. It has been an incredibly handy skill: I never use vi for anything larger but these days I actually do 'vi /etc/fstab' myself instead of calling for emacsclient.

However, I've been toying around with the idea of eventually writing a minimal 'vi' clone that you cannot exit. I'm sure there's pent-up demand just waiting for one!

I think emacs is the winner here. It's true beauty is that most users have remapped everything so all you can do is bruteforce your way to the exit.

And where do you get exiting an OS? We don't know... maybe another OS...

Usually people don’t remap the menus much so I think if you clicked around the modeline enough you could pull up some help and eventually figure out the binding for kill-emacs or execute-extended-command.

How do you exit, then, if you never learned :q?

He never did, some say he's still in vi to this day.

The story of every 2 out of 3 vim users

4 out of 3* FTFY

Or perhaps it's 5, or 6.

ctrl-z to background it. Then `kill` it.

That was how I'd exit vi for a long time. Often "killall vi" because any other vi instances running would in any case be by accident.

I once caused a near rebellion of vi users when I was running an ISP and symlinked vi to emacs on our shell server because I was sick and tired of it...

Switch to a different terminal, log in, find the process, kill it.

'screen' uses C-a as a prefix shortcut so developers of 'tmux' decided to use the next available key to avoid clash.

I don't understand the logic there. In what non-contrived scenario would you run both simultaneously, such that they would conflict?

C-a does annoyingly conflict with readline's "move to start of line", though.

Hitting C-a twice sends it to the terminal.

Close... "C-a a" sends a real "C-a", while "C-a C-a" swaps with your most recent window (it's fast and convenient to type).

1. Outer tmux on local/primary machine, for your usual daily use-case (i.e. managing multiple terminal sessions).

2. In outer tmux, ssh to some other machine you need to administrate.

3. screen because you need multiple terminal sessions on that machine, or need detachability/reconnectability for some long-running process.

Also, many older production machines don't have tmux, so nesting a screen session happens. This is starting to not be a thing, but it was a thing for the trailing 10 years.

My understanding of the history is that the developers of tmux were using screen to develop tmux, because tmux didn't exist yet, so they needed a non-conflicting keystroke.

Obviously they could have switched before a general release, but I guess they had gotten used to it.

At work, my desktop has tmux, but the servers we deploy on only have screen.

Emacs is so dynamic and easily configurable, that people can actually rebind a lot of things when their colleague go to the bathroom as a prank.

Just open a scratch file, enter some s-expressions, evaluate them, then kill the buffer.

The last time I went to the bathroom as a prank HR had to have another talk with me.

Never go to the bathroom as a prank.

That's why my scratch buffer is by default NOT in elisp mode

You can evaluate an elisp expression anywhere in any mode.

As an aside you can also make a (non-elisp) scratch buffer on the fly: when you switch buffer just enter a name that isn’t taken (I usually use b, bb, bbb, ...)

Would serve the victim right.

Never leave your unattended keyboard and screen unlocked.

At some place I worked there was a policy that a small prank was allowed if the workstation was not locked when someone left. I'd almost recommend that policy for some places.

Acceptable pranks would be things like:

- innocent videos (annoying videos for toddlers etc)

- change Spotify playlist from rock to childrens songs or rickroll or something

- open MS Paint and draw something (those pranks weren't necessarily small, we got three huge monitors side by side on those workstations)

- etc

Unacceptable pranks:

- anything that wasn't possible to revert in a hurry

- anything a customer couldn't see (we were on display :-/ )

At another place I know someone sent a mail to the team from someone elses account that they would bring cake the next day.

I once burned myself by doing what I thought was the obvious thing: leaving a message in a text editor and locking the machine. Turns out for some reason he couldn't unlock it after it had been locked that way and he needed to leave the campus to have IT at the main site unlock it. (When he locked it he always did it by closing the lid instead of through the system menu.)

Nice.

I did something similar w/ tmux: map the prefix key to C-a and map CapsLock key to Ctrl (never found real use for it). So Ctrl-a (actually CapsLock-a) is very ergonomically pleasant.

What about moving to the beginning of a line?

I did the same thing but I also mapped Ctrl-\ to send the "prefix" (helpful for neated tmux sessions), so I just hit Ctrl-\ for beginning of line.

(Although this seems to have broken in recent tmux releases on Debian (3.x?) and I haven't looked into yet.)

Ctrl-a + Ctrl-a, works like a charm :)

  | However, I've been toying around with the idea
  | of eventually writing a minimal 'vi' clone that
  | you cannot exit. I'm sure there's pent-up demand
  | just waiting for one!

If a user space program can be truly unexitable without restarting (including the possibility of killing it through another shell, of course), then would you consider it to be a bug in the operating system? Seems a reasonable conclusion to me.

It would indeed be a bug, which is why any self-respecting operating system should include uninterruptible vi in the kernel /s

I once played a maze game on X where the maze would literally not allow the mouse cursor to go through the walls so it would be taken hostage. The only way to continue your X session was to solve the maze. That was quite funny. Oh, well, there could have been some other keys that would have done something about it but it was fun anyway.

Alt+SysRq+k

(read linux/Documentation/admin-guide/sysrq.rst before you try this)

> A similar optimisation was with tmux to bind the prefix to C-z. It's in a handy location next to ctrl and I very rarely use suspend anyway.

I think gnu screen has the right idea here: ctrl-a.

And you say z is close to control - does that mean you use emacs without shift lock as control?! (I mean sure, still closer than b...).

Caps lock isn't shift lock though.

I know, because I have triple-shift-press mapped to shift lock on my Ergodox. It's... usually better, but sometimes I type a @#$%@#$% swear word when I mean to enter a number.

> And you say z is close to control - does that mean you use emacs without shift lock as control?! (I mean sure, still closer than b...).

Presuming Shift Lock means Caps Lock, that and Control are both close to Z on my (Apple) keyboard.

I use ctrl-a quite a lot on the command line, though.

C-a is the worst default keybinding ever, since like, going to the beginning of a line is one of the most common operations.

Well, not with proper key bindings ;) (set -o vi)

In the rest of the universe, going to the beginning/end of the line is mapped to the Home/End keys (fn+left/fn+right on Macs), and I do prefer it when my thing does things in ways that roughly correspond to how the rest of the universe does them if there's no compelling reason to do otherwise.

> (fn+left/fn+right on Macs)

When I used Mac in 2009 to 2012 it depended on the application you were using:

Some used fn+left/fn+right, some used CMD+left/CMD+right and I think ctrl and/or alt + arrow keys were an option too.

ctrl a/ctrl e would work everywhere I think but I didn't use those as they didn't work with shift to select to the start or end of the line.

As a keyboard type of person this was a major part of what drove me away from Mac despite its many advantages :-(

I have remapped capslock to be an additional ctrl so I hit C-z easily with my pinky + ring fingers.

C-a (like in screen) would be even better but as others have pointed out it masks going to the beginning of line which is very common.

C-z is very rarely needed. C-q/C-s would be good candidates also as I don't think I've ever needed flow control in this century nor the last one, for that matter.

command wq <nop> command w <nop> command q <nop>

Unfortunately:

  E183: User defined commands must start with an uppercase letter

command W <nop>

cabbrev w <c-r>=(getcmdtype()==':' && getcmdpos()==1 ? 'W' : 'w')<CR>

cabbrev q <c-r>=(getcmdtype()==':' && getcmdpos()==1 ? 'W' : 'q')<CR>

cabbrev q! <c-r>=(getcmdtype()==':' && getcmdpos()==1 ? 'W' : 'q!')<CR>

cabbrev wq <c-r>=(getcmdtype()==':' && getcmdpos()==1 ? 'W' : 'wq')<CR>

Had the same issue with C-x C-c; I remapped mine to C-x C-c C-t because it worked for me as a mnemonic (assuming a "soft c"): "ex-s-t" => "eckst" => "exit"). Major productivity boost!

- So, how did you learn Vim? I heard there's quite a learning curve.

- I just open it, but I couldn't figure out how to quit. Then I have been using it for three years already.

(Same applies to Emacs.)

> - So, how did you learn Vim? I heard there's quite a learning curve.

You can go through the interactive vimtutor.

Type :help tutor

Or you can just type :help and find the link to the vimtutor. If you are using gVim, then it should be one of the menu items ( maybe under help? ).

My suggestion is to just search for basic vim cheat sheet if you are getting started. There are also youtube tutorials online. Sometimes watching someone work with vim can help you get over the hump.

> - I just open it, but I couldn't figure out how to quit.

:q to quit.

:q! to quit without saving.

Remember to hit ESC to get back to the normal mode first if you are in other modes.

When you are comfortable with Vim then you can go on to some of the advanced vim topics. Also, in the beginning you might have to ddg/google/etc a bit. Good luck.

I have tried to start using vim so many times and failed. Even this year I thought to start using vim. Daily I open vim once try to do something new with it. Although I don't have much of hope that I will start using it an soon.

I first used vi / vim about 30 years back. There are other editors that provide fancy features and I do use them routinely but there is no day I have not started (and exited) vim. Get used to it.

As a sysadmin, not a programmer, what I found helpful for learning Vim was not to try something new each day, but to find one or two commands that were valuable enough that I would at least open Vim somewhat regularly. The two that did it for me are delete line (dd), and change inner word (ciw), both extremely helpful for config file editing, especially when combined with repeat command (.)

After learning these first simple commands, it was enough to get me to open Vim at least a few times a day, which then motivated me to start learning more of the commands and it just snowballed along. I still only know probably 25% of Vim, but I feel incredibly comfortable in it now and rarely run into trouble when doing beginner to intermediate editing tasks.

As a fellow sysadmin, I would advise to learn vi properly then switch to Vim because the former is pretty much everywhere, and for example you could mess the file with cursor keys in Insert mode instead of using hjkl in it.

That's good advice, but in all practical situations I have been able to use Vim directly or know enough vi to get by, though I am much less comfortable with it.

I don't touch type, so hjkl, even though I understand the benefits, has never been my preference. Perhaps it's the gamer in me, I've never had trouble using the arrow keys :)

As far as I know, hjkl was first introduced in games and later used in vim because we don't have to move our hands far away from the keys.

Feel free to correct me If I'm wrong.

https://catonmat.net/why-vim-uses-hjkl-as-arrow-keys

One neat thing this misses is that in ASCII, H is left, CTRL-H is backspace (which goes left while doing a thing); J is down, CTRL-J is linefeed (which goes down while doing a thing, sorta). It ends there, unfortunately - I don't see a good connection between vertical tab and up or formfeed and right.

The idea behind trying something new every day is just that I know what are the thing that are possible not to learn it by heart.

For example, Now I know if I need to go to the next instance of the word under the cursror. There's a command for it.

I've made quasi-regular attempts to get truly comfortable with both Emacs and Vim at various points over the... last two decades, honestly. Strangely, I was always a little more comfortable in Vim, even though the other editors I've been comfortable with through the years have been modeless. Last year, though, Vim actually took for me, and I think there were three reasons:

(1) Buying the book Practical Vim from the Pragmatic Programmers, which is aimed at people who kinda-sorta know Vim but don't know much of Vim. I still haven't truly internalized a lot of what I've read, but just understanding the magic of ":find", "." and a slightly greater number of the Ten Thousand Ways to Select has been amazing.

(2) Trying to do as much as possible with "native" commands rather than plugins, then adding a smaller number of considered plugins back in.

(3) Having a real project -- of sorts -- to work on and sticking with Vim for that project. In this case, the project was going through the entire Pragmatic Studio course on Rails 6. (It's good.)

I'm pretty sure these same three steps would work for learning Emacs, too. (Obviously with a good book on Emacs in step 1, not Vim, yes, yes.) But I'm actually pretty happy with Vim.

Also, the proper way to quit MacVim is clearly to select "Force Quit" from the Apple menu.

Thanks for the book suggestion. I will definitely check it out.

I learned the 2nd point the hard. The first time I tried vim, I added as much plugin as I can end. In the end, it was a giant mess.

I finally started using Vim sort of by force, and am already becoming proficient with it after a few hours (and liking it). The reason was that my ISP sent me a cheap Chromebook for free, and I've started using it for coding during my commute (and relegating my old laptop to my music studio). A few days ago there was a ChromeOS update that seems to have killed the ability to connect to code-server (a VS Code server) from the browser, no matter what I tried, and then I tried my old trusty Emacs and I can't get MELPA to detect go-mode at all.

Infuriated by all of the above I found a nice tutorial on how to set up Vim for Go development, used vimtutor, and now I've been able to do non-trivial amount of work while on the train. I actually rather enjoy vim now.

You might want to check out https://vim-adventures.com/

I very much enjoyed the first level. Already quite proficient in vim, I balked at the cost of the full game - but it might well be worth it in your situation.

I'm not sure if I should mention it here, but in case some people are not familiar -- these lines make using vim a very easy experience for those used to CUA editing interfaces:

  set nocompatible
  source $VIMRUNTIME/mswin.vim
  behave mswin

It doesn't really change the command mode if you're used to traditional vim, but you can use shift-arrow keys to select text in VISUAL mode, use CUA commands like C-c, C-x and C-v, etc. Keys like Home, End, C-insert, and S-delete also work.

Spacevim is very user-friendly. Or at least as close as vim gets.

One day several years ago I found a ~15 year old laptop on the side of the road and wondered what I'd do with it. 300MHz processor, "what's Ethernet?", and I didn't have the little pile of flaky USB Wi-Fi dongles I have now.

And it was only through attempting to actually install from the Slackware CDs I'd burnt several years earlier that I discovered the scratches on them were unfortunately not just decorative scars.

So: gcc, corrupt. g++, corrupt. Python, corrupt. Perl, corrupt. sed, ...not corrupt. grep, also not corrupt.

I love working on little projects. At one point I noticed that installing specific packages quickly and easily wasn't straightforward because I couldn't see what was already installed.

dialog was among the uncorrupted, and I wondered if I might use this to show installed and uninstalled packages side by side.

That was when I discovered the info pages were also intact, and that sed and grep both had excellent info documentation.

Unfortunately I deliberately gave up working on the project after a few days, as I developed headaches from staring at multiple ~5-6 line (ie, ~480 char) monster regexes over the course of a week or so. (Imagine multiple blocks of modem line noise each 2-4 times longer than http://bash.org/?464385 and you're in the ballpark.)

I do plan to finish that script at some point though (when I regain access to that laptop's HDD). It was only 5 sed commands and 4 grep commands...

I'm in the same boat. Somehow, neither vim nor emacs have ever made a compelling case for me to switch from nano which "just works"

Emacs prompts you to use the tutorial on startup if you haven't configured it.

So does ViM :)

The accepted answer here [1] is what got me to see the light. Once I realized how composable the main commands are, vi became kind of fun.

I still prefer Emacs because of macros and org-mode, but I no longer fear vi when I'm doing a quick edit, editing a huge file, or on a emacsless new machine.

[1] https://stackoverflow.com/questions/1218390/what-is-your-mos...

That was my way into learning Vi(m), too, and I also stayed with Emacs, but using Evil mode. I struggle with vanilla Emacs nowadays, tbh.

What do you do if you need more entropy? Open vim and ask a graphic designer to exit.

It's amazing to think how far we've come since June 2018 where the record was just shy of three minutes (https://www.youtube.com/watch?v=TLbfqZBL8t8). These new strategies could allow experienced speedrunners to exit vim in times of 10 seconds (or perhaps less!?). I'm excited to see how this progresses, the vim speedrun community is vibrant and creative and I've no doubt we'll see a sub 5-second run within my lifetime.

I believe the solution to this lies in using Rust and SIMD. It will achieve both performance and safety.

I would prefer a functional approach and formal verification so we can know for sure it will exit.

Since the real world is not necessarily deterministic as demonstrated by the methods using random(), I hope to see more development in stochastical methods describing parameters of probability distributions of successful exits.

In the face of vim's unyielding resilience to exiting, I think we may need to devise a new algorithm for this using quantum superposition. I heard IBM can help with that.

But who would support it? While a formally verified functional approach may satisfy one's doctorate requirements, the author will graduate and move onto blockchain development, leaving behind an exit-vim code base that no other engineer could possibly understand without the equivalent training. Upon receiving said training, an engineer would also take newly acquired doctorate and also move onto blockchain development. Essentially, supporting a formally verified functional approach to exiting Vim creates a pipeline of well-credentialed and rigorously trained professionals for blockchain development. If Vim were, however, put on the blockchain, we may be able to address this concern and you can get what you wanted.

Or, you could have just used Rust and SIMD.

This hits so close to home.

Let me halt you right there...

Pretty sure there will be a TAS in the sub-second range in the near future!

I'm confident we're at the dawn of a new era of AI driven vim closing.

My first attempts ended up with my bot buying stock in a clorox brand before posting questionably racist comments to my twitter, but these are minor concerns on the journey.

I'm streaming the process on twitch but please note that donations won't be considered as seed capital for stock assignment

Must be GDQ season again.

There is a much faster way, but first you need to build up speed for 12 hours.

I'm curious if there is any work in fuzzing that could be applied here.

First step to quit vim is to accept that you are vim user.

Here are some tips:

Try to limit yourself to one vim session per day, then one session per week, and so on.

Try to replace some Vim sessions with Emacs.

Buy notebook with keyboard without Esc key.

Install an OS without Vim.

Use mouse.

> Try to replace some Vim sessions with Emacs.

I thought you said quit Vim, not go running back into its warm embrace.

> Install an OS without Vim.

The hardest of the steps ….

> use mouse

Noooooo! Not that! Please not that!

Why not? It works with VIM and NeoVIM. (-:

"Buy notebook with keyboard without Esc key."

So now we see what Apple was trying to accomplish with the Touch Bar.

>Use mouse.

OMG I use pretty much the default settings in vim but set mouse= is one of the only 2-3 things I put in my vimrc!

The macbook pro and old thinkpads are the only laptop computers with decent built-in pointing devices, all the others always end up coupling with my palms and randomly munging my code!

> Try to replace some Vim sessions with Emacs.

Done because I love org mode. What's that? Evil mode? Nah. That's nothin. Ignore it.

> Use mouse

I am ethically opposed to cruel and unusual treatment of *Nix users.

You can pry my tiling WM and Tridactyl/qutebrowser away from my cold, dead hands.

I know of the perfect 12 step Vim Anonymous program that helped my brother in law finally get free

See your doctor if you experience smug overweening superiority over your fellow developers greater than 6 hours at a time.

> Buy notebook with keyboard without Esc key.

Won't help. True addicts know of C-[.

I would recommend against making a decision to turn your will and your life over to the care of RMS, though.

One of my Computer Science lecturers had a rule: use Vim for all development for his class whilst on campus, and if caught using any other editor/IDE – or committing any artifacts showing evidence of such – we would lose several percentage points from our final mark for his class.

Harsh? Perhaps. But I can’t thank that lecturer enough for that rule. He converted a mostly IDE-wielding class into one that actually appreciated Vim, and most of us still use it or its key bindings.

Edit: this was in 2018, when VS Code, etc. were already popular.

This is more or less what I did, but under my own motivation. I charged myself to do all my CS homework in vi and had a copy of O'Reilly's Linux in a Nutshell at my side. It didn't take more than a couple of semesters and I didn't need the book at all.

Had the same thing when I was studying CompSci.

Ended up spending more time configuring vim than doing the work I was supposed to do.

Even did the completely pointless exercise of making custom syntax highlighting for the pseudocode language we had to use.

This prepared you for the 'real world' better than any programming lessons could!

Once configured vim works fine. I probably spend 1-2 hour/day in vim for my personal projects but haven’t configured anything in months.

I think I had most things working properly within the first few days, but kept customizing and changing settings/fonts/themes/plugins.

Mostly procrastinating by pretending I was "Being Productive"

That's stupid and elitist. There's no reason to force students to go against IDEs that they're already used to, but also the general method of navigating around a computer which they're probably used to from MS Word etc.

I've found myself learning stuff better when there is no IDE correcting me all the time and auto-generating stuff out of thin air. IDEs are awesome once you know what you're doing but I do also see the reasoning for forcing to use an ancient (and still quite powerful) editor.

Disclaimer: I do most of my coding in Vim but use IDEs every once and a while.

I disagree completely. When I took CS036 in first year engineering, it was a C++ course that used Visual Studio and while I received a good grade on that course, at the end of it I did not know how to invoke the compiler from the command line. I only knew how to build software from the drop down menu in VS2004 or whatever version it was.

IDEs are a crutch.

Sure, but invoking a compiler from a command line is something you can easily pick up from a coworker or an internet tutorial.

The primary focus of an intro engineering course is (usually) about the theory and structure of computing, along with general techniques for writing code.

Learning about various build tools distracts from that focus.

EDIT: Also, you seem to be implying (apologies if I'm wrong) that invoking a compiler from a command line is somehow "better" than using IDE. Why?

My intro course used BlueJ, which is (was?) some sort of dumbed down Java IDE specifically for students. The thought was that dealing with all of the crap surrounding software development, like make systems, editors, compiler flags, etc was a distraction from learning basic programming constructs. Looking back I agree completely. As a new programmer, things like compiler flags are pretty much black magic. You don't really learn anything by reciting magic spells.

Learning development tools like the CLI, IDEs, debuggers, linters, et. al. should be required for a CS degree. I don't think an intro course is the right setting.

If this was at work, or if this was for every class at a given university, I'd agree with you. But, in a place where you go to be challenged intellectually and open your mind, why not? This would be perfect if the same professor forces everybody to use a specific IDE in a different class...

I’ve seen Java developers completely lost with no idea where to start debugging an installation in a lab environment because they had no IDE, JDK only. Sure, you might argue that it’s an unlikely scenario, but never say never. CS is one of many fields where having a basic understanding of how things work at least a couple of layers of abstraction down is a good thing, and at least could save potential embarrassment.

You're not wrong, but I don't see how forcing people to use vim solves this problem. If anything, you risk having a whole class of students who can only do things the vim way. I'll grant you that you're much more likely in a lab environment to have access to a POSIX system so you can use vi or whatever, but you could also wind up in a shop that dictates its devs use a specific IDE.

I'm in full-agreement that it's a good thing to have a basic understanding of how stuff works, but I'm not sure how enforcing vim over VSCode or Sublime or [insert your favorite editor] necessarily teaches that. It teaches adherence to vim.

I'm of the opinion that programming tools are very personal -- that's why there are so many debates and that's why we'll never have universal agreement. I know my way around the command line and I'll suffer through vim if I have to (it's fine. It's just not my editor of choice), but if I don't have my dotfiles or configurations, I'm not going to be very productive either.

I'm fine with saying, "don't use an IDE in my class, use a text editor" -- but I find it draconian and ridiculous to insist upon a specific text editor.

I should have been clear that I lean toward your side of the issue in that a blanket policy for the entire term does seem a bit extreme but completely without value. If I were pushed to defend the instructor’s policy of a particular editor, vi is nearly certain to be on any Unix installation. Not necessarily how I would (or have) done it, but the approach is not without value.

My preferred Unix editor is the vi family. I wonder whether emacs people are less sympathetic.

It’s a college class in which students are supposed to learn something new, that seems like a perfect example of a situation where you should be forced to do something outside your comfort zone.

I don’t interpret that as the college professor saying this is actually the best way to code, just that forcing students to struggle through it is a learning experience.

> It’s a college class in which students are supposed to learn something new

Unless the central thrust of the course is supposed to be the mechanics of a particular dated editor, the restriction described seems to be a distraction from rather than an aid to what the students are supposed to be learning.

It doesn't make any more sense than a social science course where the deliverables for most assignments are essays mandating WordPerfect for DOS. Sure, you'll learn something you might not otherwise, but it's a distraction from what you came to the course to learn.

Modal editor are not dated. You’re saying this as if the command line itself is dated. It’s not, casual user can go ahead and use Windows or Mac, but shell and she’ll editors will not in the foreseeable future be dated.

Vim is far from dated, and comparing Vim to wordstar shows how little you understand it

I suspect the rationale is that, depending on the language you're using, some IDEs "help" with coding to the point where they're correcting your mistakes and even writing parts of your code for you. This is pretty much a selling point for everything JetBrains makes, and arguably even Visual Studio Code rubs against the edge of that if you're using a language that's well-supported by IntelliSense. The central thrust of the course is presumably how to write code yourself, and the case could be made that learning with an editor designed to routinely save you from yourself isn't going to be as good as an editor which, well, isn't.

(This is setting aside the argument as to whether Vim is a "dated" editor. Vim is an old editor, to be sure, but forget WordPerfect -- it's not as old as Microsoft Word is!)

I still prefer what they made us do for the test: Write the program on paper.

> particular dated editor

I wonder how you feel about age discrimination. Old != bad.

I started using Vim when I was 14; I was the only one in the class who wasn't using an IDE. Vim (perhaps combined with a language server if you're okay with the complexity) runs circles around bloated IDEs like IntelliJ/VSCode. Unix combined with a tiling WM is the best IDE in existence.

The professor in question is likely doing the students a service by showing them the advantages of minimalism and function-over-form over the trend of bundling an OS with every "app". Many students today only feel comfortable using software that saturates their synapses with colors and animations; having to use Vim for a semester forces the good ones to realize that maybe, just maybe, function should come before form. Maybe 10k lines of C or POSIX shell solves a problem better than a VC-backed Electron app.

To continue your analogy, WordPerfect and DOS, unlike Vim, aren't better than today's tools. What would be an improvement is LaTeX/BibTeX for writing essays. Once I realized how much work was automatically done for me--from Chicago-style footnotes/endnotes and auto-generated ToC from headings, the time I spent formatting my papers dropped to zero. I would absolutely incentivize students to use these tools over "modern", bloated word processors.

Cool, I use nano. Should I be penalized?

Minimalism for the sake of minimalism isn't what I was arguing for. If it were, I'd say that every paper and program should be written with `ed`, the standard text editor [0].

What I was trying to say was that if minimal solutions run circles around bloated ones thousands of times their size, and when it takes a startup and two funding rounds to develop something that does exactly what tools did three decades ago less efficiently, then maybe Braithwaite was on to something:

> “It’s a curious thing about our industry: not only do we not learn from our mistakes, we also don’t learn from our successes.” -- Keith Braithwaite

[0]: https://www.gnu.org/fun/jokes/ed-msg.html

In 2018 - this is so bad that it deserves some kind of disciplinary measure from administration.

This is absolutely unacceptable for students needing different accessibility enabled tools other than vi /vim.

For example, if using an alternative screenreader or a vocally/sound enabled ide or if needing to interact with a text editor via a brail enabled tool that doesn't work with vi, does the student just get failed out? That's a lawsuit waiting to happen.

...This is a bit of an overreaction. I think it's safe to say that the professor won't fail any blind students simply on the basis of being unable to use Vim.

ex, something that comes with every installation of vi, is completely accessible.

Some of the vi clones do not have an ex mode, note. NeoVIM has neither ex nor open modes, for example.

He should at least allow emacs.

He might find my vim configuration looks a lot like an IDE with almost 60% of feature of one. (Except compile, I like to use command line for that)

Love to trap my students in the 90s and pretend no progress has been made on editors since.

I'm glad you had a good experience with this, but I can tell you right now that if I had a professor insist I couldn't use my own tools for his class out of what appears to be nothing more than "you will use what I force you to use because I believe only REAL programmers use vim," I would be the type of student who would take great pleasure in using my text editor of choice discretely and doing whatever I could to ensure there was no proof that I was using my tools of choice.

I'm fine if a professor wants to say "we're not using IDEs, we're using text editors in this class and this is why" -- but to dictate the editor would be akin to being told what type of pencil or pen I could use to take hand-written notes.

It reminds me of one of my writing professors who insisted that all papers presented to him be formatted in Arial. Arial is a bad font, so I asked if I could use the metrically identical Helvetica, and he refused. I still submitted my papers in Helvetica anyway and he never noticed.

(I'm not claiming this is a mature response, FWIW, but a core part of my personality naturally pushes back on anyone telling me I can't use something for a wholly arbitrary reason or because they want to enact a ridiculous level of control.)

I am a Vim user, and if I had a group leader tell me that I had to use some different editor because we are all learning how to do this job together, and that learning how to use the editor properly was part of learning how to do the job, I would do what he says. At least for as long as he stays in the room...

On the other hand, we had an architect who has since retired that said, if it was up to him, all developers across the campus would use the same programming language, editor, and configuration. Thankfully it was not up to him, and we still have this lovely diversity of opinions and tools that signals it is encouraged for specializations to develop, thus making sure that we are not all replaceable cogs in an exceedingly boring machine.

But the memory of this man's twisted vision remains with me, and it strikes me that the leadership still would seem to prefer if we were in fact fungible units of work-capacity, without any distinctive features or unique characteristics differentiating us from other developers.

IMO if you learned to ensure there was no proof of different tools, you learned an equally valuable lesson; I would mark you down for example if I opened your file and found a bunch of CRLF line endings, or some other similar obvious linting violation that was prevented by an editor configuration you were supposed to have installed during the class. But if you applied enough attention to detail to make sure this was not possible, in a way you got the point (and also for the purposes of the grade, you definitely got the point!)

I would do as they said if they convinced me that they had sound reasons for the choice. I don't think they'd be able to come up with sound reasons for dictating vi specifically, over a more lenient requirement, though. And being dictated to like that without sound reasoning behind it would instantly make me rebel. Unlike the other commenter, I would not do so quietly - I'd be more likely to make sure to use whatever he'd take most offense at in front of him, and seek to rally others to that cause.

I just sat through a two day training/workshop session called "Design Thinking" during which we learned about techniques to interview stakeholders, and how to empathize with their needs and concerns (specifically without solving the problem at hand, or trying to solve it.) My perception is that I am closer to the problem than most of the other classroom participants, and I have more than enough experience to solve it by myself, without any help.

It was very difficult to follow the guidelines for the exercise and refrain from simply going ahead and solving a problem that I've solved many times before in a way that was familiar to me. In my view it would have taken less time to simply solve the problem than to engage in this seemingly "pointless" exercise, but I do think I understand better after taking the time to convince myself that those other points-of-view have merit and should be taken into account.

Maybe I simply have a case of the old Stockholm syndrome, but between you and GP, I think I'd rather have a more cooperative and acquiescent person on my project team, for the grade. Sounds like a bikeshed argument. First we said the choice didn't matter, that it was less important than the actual programming content of the class; now we're actively combating and making a big stink until someone does some argument dance about it, and convincing happens, so the justification for the specific choice is judged acceptable. (And I guess you've already dug in your heels by this point, and won't be convinced no matter what the reasoning offered.)

What would be your reasons for rejecting vi, specifically? It seems to me that we've actually rejected the idea that editor choice is unimportant; if it was so trivial and doesn't matter which editor, we probably wouldn't be fighting about it, nobody would mind the seemingly arbitrary decision. Nobody would ask for sound reasons to justify.

I don't like vi, but that's besides the point - I'd fight it exactly because I'd see it as a pointless restriction that indicates dysfunction, and I'd see that as reason to protest it in itself.

If the point of the course had been to learn vi, or the teacher had given a compelling reason for why specifically vi, rather than less specific instructions, then I might have accepted that if their reasons were good enough.

Honestly I really hate being forced to use any particular piece of software and I love vim!

I'm really happy my algorithms professor let me use Makefiles and vim even though the standard tool at the university was (blegh!!!) visual studio.

Everything I'm about to say, I say as a Vim/Evil user who avoids IDEs like the plague. I like Vim. I like composing commands on the fly, I like modular editing, I like that I can magically format CSV files with quick macros, and I like jumping around my editor like I'm Spider-Man. Heck, I swapped out my window manager with EXWM and Evil just so I could use Vim-style modular commands everywhere.

But learning Vim isn't related to learning how to program. In that context, it's a pointless distraction.

Be honest -- when was the last time that you or anyone you know had a programming assignment at work and came back to scrum a week later saying, "I'd have finished this, but navigating around my editor just took up too much time?" >95% of programming is going to be bottle-necked by the speed you think, not the speed at which you can edit text.

So it's like forcing all of your students to learn Dvorak, or to submit all their written work in cursive. Undoubtedly a few students will thank you for it at the end of the class because some people do get real value out of learning those skills -- but just as many of them will say you wasted their time, and they'll be right. I write in cursive too; it's an objectively faster, more pleasant way to take handwritten notes. That doesn't mean that learning cursive has anything to do with learning to write books.

To any professors on HN reading this: if you're teaching a programming class, please teach programming. Because if students just wanted to learn something new, or to be forced to struggle with something outside of their comfort zones, there are a lot of cheaper ways than college they could do that.

Even with that goal -- a programming professor can't come up with any outside-the-box assignments more related to their subject than "learn Vim"? I can't fathom that kind of lack of creativity in a field this broad.

I'd have taken the loss in mark on principle over something like that.

I used to be a vim evangelist before, but after seeing some of the people at my lab writing code as fast as me in Sublime Text, I’ve decided not to participate in editor wars anymore.

Jokes aside, shouldn't the page start with actually teaching how to quit vim?

The page is considerably popular to show up on a Google search. I imagine the frustration of a beginner actually trying the first examples and not getting the joke immediately.

I'd bet that most people who get stuck don't start vim themselves though. I taught (the basics of) git to a bunch of students recently and the first time we did a commit I had to go around the room and show people how to operate vim. I bet the same happens when new people use visudo, etc

This is why vim is a bad default. Thankfully, there's someone thinking about changing this [0].

[0] https://www.phoronix.com/scan.php?page=news_item&px=Fedora-W...

I don't know about vim, but in neovim you're greeted by the following when you launch it the first time:

type :help nvim<Enter> if you are new!

type :checkhealth<Enter> to optimize Nvim

type :q<Enter> to exit

type :help<Enter> for help

This joke is pretty outdated :P

(But still kind of funny)

You get the same thing in vim, but only when you open it without a file. Chances are, you only do that when you're already a vim user, and most non-users will be confronted with any random program opening a file in vim for them to edit (visudo, git commit, etc.)

git will open pico if you haven't configured an editor. It's annoying.

If you have configured an editor, hopefully you already know how to quit.

It has to open something, and pico/nano, at least, has a menu that tells you how to quit. What else would be a preferable default?

I'm open to the idea that there isn't a better default, but that doesn't make it less annoying.

Another option would be to fail and prompt the user to configure an editor preference. That wouldn't be much different (to me) than what it does now.

Yeah, I mean if you really wanted to help people exit Vim you'd trap Ctrl-c in command mode and print the instructions at the bottom of the screen.

Something along the lines of "Type :qa and press <Enter> to exit Vim" would probably do it...

At this point, learning how to exit vim by yourself is just standard hazing practice for new devs.

It's not a bug, it's a feature.

This kind of advice confused me early on because I didn't realize the : was part of the command for way too long. For beginners, you might want to spell it out further as: "shift and the : key, then qa, then Enter"

I think that's a great suggestion and probably gets the root of the whole exit vim meme.

I don't have a qa key though

I’ll laugh about this now but then probably find out later that it was actually based on an obscure teletype terminal that actually had an “qa” key.

Yes, the version on my machine prints

    Type  :qa!  and press <Enter> to abandon all changes and exit Vim

You're only targetting old 1970s terminal users, there, though.

If you wanted to also help slightly more modern users who are used to CUA conventions from GUIs, you would have the [F1] key bring up some form of help screen, which said something like "Get out of Vim: Use :qa!" at the top.

You're only targeting old 1990s GUI users there, though.

If you wanted to also help silghtly more modern users who are used to discoverable-UI conventions from mobile apps, you would have it so shaking your device brings up some form of chat bot, which would suggest asking it how to quit Vim.

1980s. [F1] is CUA 1987.

And one of these ideas is not like the others.

Clippy, please tell everyone how Lio's and my if-only-VIM-did-this ideas are different to Kerrick's idea.

Nope.

The best thing that can happen to a beginner is they continue being frustrated with vim, quit it before they get in too deep, and just use shitty idees like the rest of us trash.

My first go at vim was an accident. I was using git and ended up there. I later tried to change the editor invoked by git to something else, but have concluded that was dumb and the only real option is to learn vim. It's still on my todo list. As is the actual OSS work I want to contribute after climbing this hill. It should not be this way.

You don't ever tick that item on the todo list. Learning vim is a never-ending path to wisdom.

VScode's text editing/ diff/ git tool is really good.

It helps that VScode is also my editor of choice in general.

The question is not "How" but "Why" you would want to ever do that in the first place;-)

Many years ago I knew a university professor and students said about him he might leave uni occasionally but he sure never leaves Emacs. Some live in Emacs, some live in Vim.

I live in a different universe to you it seems. The only vim command I know is :q.

Honestly, I tried several times over the decades and walked away with my head buzzing.

PS: I don't live in emacs either!

What I do love in both camps is how the explanations begin... "All you have to do is...[insert irrational (to non-vim/emacs users) command]" which makes me laugh every time.

Love the article, which ironically proves my stance of me keeping well clear.

I know some basic commands and know it well enough to edit git commit messages and interactive rebase (`ddkP` is probably the most advanced command I know). But I've never thought "I prefer this over my regular editor this is amazing". I just don't get the satisfaction.

And of course I'd have to dive deep into the ecosystem in order to get the same benefits that my main editor provides out of the box, like idk, cmd+click to go to definition, or error reporting like squiggly red lines.

> And of course I'd have to dive deep into the ecosystem in order to get the same benefits that my main editor provides out of the box,

To me, vim shines as a modal editor, not an IDE. I use it for two purpose:

1. quick editing configuration files, or single file scripts 2. an editing mode in an IDE (mostly VSCode)

The main benefit of vim is to save you from using the mouse or the touch pad. I touch type, my indexes rest on F and J, and I can do pretty much anything without leaving the keyboard, without using the arrow keys, and keeping my eyes on the screen. It's not something I'd know how to do without Vim. If I'm using the arrow keys, I need extra-time to relocate the "J" key, which breaks the typing flow.

My hypothesis is that vim style work (without moving a wrist even a bit) is the reason people get carpel tunnel. I anecdotally see far fewer (none?) People who don't do vim/emacs getting these injuries. Makes sense as well right? Just like "take a walk and don't sit in the same place" but for your fingers

I don't know about carpel tunnel, but the reason I became interested in Vim/Emacs was due to RSI caused by using a mouse. This was my first job, doing shudders Java-EE (7) web development (no live re-loading, tons of clicking in IDE, manually reloading web-page etc, crappy windows touch-pad etc).

Started learning Rails, drank the Kool-Aid, switched to VIM. I don't use VIM for development at my day-job, mostly just key-bindings in Intellij/VS Code, however, the amount of time saved has been worth the effort, and no RSI (also thankfully am able to use the fantastic track-pad on mac and a trackball for anything else).

Lately I've been feeling the pull to learn Emacs after learning about ORG-Mode and the extensibility of the software... unfortunately, the time investment here is likely to have no real benefit in my (current) work as a Java dev. Sigh, time to browse the who's hiring thread.

Using Vim has helped my finger/wrist/arm/shoulder/neck pain and soreness, but you're on to something in that the real problem is probably more repetitive motions than any specific motions.

But Vim (and emacs) solves the repetitive motion problem by providing several means of readily repeating commands.

Most people seem to both type and use their mouse much more slowly than I do. And they also don't often have to (or want to), e.g. cleanup thousands of rows in an Excel worksheet, or have to repeat some kind of action in an app or web app dozens of times.

But I hate using my mouse generally. There are very few times where I want to use a mouse and having to use one, instead of being able to use the keyboard, is endlessly frustrating.

Thankfully, there are several great 'vi-style' browser extensions and there's even [Vimac](https://vimacapp.com/) for MacOS, tho I haven't tried the latter yet.

Maybe that's a bit like saying that running shoes are harmful because people with running shoes sustain running-related injuries more often than the average person, who in reality just doesn't run as much.

If you don't like vim for that you can point to another executable by setting gitconfig core.editor to an executable command which starts an editor of your choice. Mine points to Notepad++ (Windows box with msysgit installed).

Mileage may vary depending on language support, but vim does have a go to definition feature[1][2]. I believe there is also out box error checking for some languages, and if that is not enough for you (and at the risk of offending a large number of vim purists), there is a fantastic plugin called ALE[3] that will likely provide you with what you want.

1: https://vimhelp.org/pattern.txt.html#gd

2: https://vimhelp.org/pattern.txt.html#gD

3: https://github.com/dense-analysis/ale

> `ddkP` is probably the most advanced command I know

Maybe I'm not thinking straight because of the sickness, but I think `ddp` from the line above does the same thing with one fewer keystroke.

`P` pastes to the line above.

That’s why the poster above suggested doing it from the line above. kddp still saves you from the burden of pressing the shift key.

(Works if register contents after the operation do not matter to you; I don’t think the OP knows or cares what registers are)

text objects are a big reason for the satisfaction for me. I spend a fair amount of time moving code around and I like being able to say "delete everything in this indentation level and copy it" in 3 keystrokes. It's pretty sweet when you're use to it and you have it customized to do what you want (which takes time and isn't for everyone).

What is the text object for "current indentation level"? One you created or is it built in?

Nitpick: 'q' is an ed command. ('ed' Being the underlying line-editor upon which the original vi was layered.)

Why make it a nitpick and not a fun fact? :)

If it were a fun fact, it would have to point out that it is an ex command. Nitpicks do not have to be quite so factual. (-:

Meta-nitpick: Vi was built on Ex, not Ed.

You don’t have to use vim command in normal text editing (mostly). Vim (and emacs) draw lies mostly in programmatically writing text.

There was a tweet quite a bit ago:

> My husband uses vim. It’s why I married him. But I just found out his email client is emacs. I don’t know how I feel about this.

The list actually has that use case covered:

https://github.com/hakluke/how-to-exit-vim/blob/master/READM...

I honestly don't know how vim deals with unsaved changes upon shutdown and don't use it enough to look that up, so that's why I'll first exit.

As to why shutdown: cultural thing in the end. I was raised with the idea that wasting is bad (and objectively speaking it's very hard to argue with that) so if I don't need the machine running after I'm done with it, I just can't stand the idea of the thing using energy literally for nothing.

Depends on how you configure your swap, backup and undo files. You can have all the extremes from "everything is lost" to "everything is saved" if you suddenly kill the vim process.

Emacs users live in emacs, but vim users usually live in the terminal, not directly in vim. Good thing there's a terminal version with vim bindings of pretty much every program out there :)

(As I finished writing this, and was about to type ^[fG to submit this reply, I couldn't help but smile a bit)

set vi!

As the old joke says[1].

  ED(1)               Unix Programmer's Manual                

  NAME
     ed - text editor

  SYNOPSIS
     ed [ - ] [ -x ] [ name ]

  DESCRIPTION
     Ed is the standard text editor.

[1] https://www.gnu.org/fun/jokes/ed-msg.html

I've written the following one-liner if ed(1) is unavailable on your system, to emulate its functionality:

    trap 'echo -e "\n?"' INT; while true; do read; echo "?"; done

:), Yeah, those were the days!

Very clever, but I wish they would put the real way, which, for the record, is

:q

at the top so that this doesn't annoy people who legitimately google it and have to wade through this.

But any of the other methods work just as well

Not by the metrics "tediousness" and "applicability to later vim usage".

This page is well at the bottom of the first results page, and vim tells you how to exit it now when you try things like ctrl+c. I don't think anyone is in danger. https://i.imgur.com/b6dqBiV.png

>This page is well at the bottom of the first results page

It's at the bottom now, yes, but if this (and copycats) takes off, it won't be. I've seen cases where the search results get so dominated by oh-so-clever parodies that are mixed in with legit answers that you can't tell which is which.

>vim tells you how to exit it now when you try things like ctrl+c.

Which is great, if that version of vim universally replaced all the others, and every newbie was aware of ctrl-C.

For context: in 2011, I tried the project Open Hatch, specifically designed for newbies, and if you followed their tutorial instructions, you could get dumped into a vim terminal with no idea how to get out.

>I don't think anyone is in danger.

With respect, I'd suggest updating your criteria for making this judgment.

You're being a little dramatic

As long as we're giving feedback, you could do better on empathy for those who don't know the same things you do.

Look at it this way: maybe this show of insanity could cause further frustration and ideally help newcomers realize that avoiding vim altogether can be preferable for their future.

Sarcasm aside, I fully agree with you.

Oh dear. What are the chances this will eventually rank fairly highly on search engines - this is going to ruin the soul of the unsuspecting people who end up thinking that this is not satirical advice.

If you don't see it's a joke, Vim is not for you. Stick with Notepad or Google Docs. Obviously, it's not aimed at you :-;

To clarify, if someone gets stuck in 'vim' when debugging an issue and searches the web for "how to exit vim" and ends up on the document linked in the OP ... your advice is "stick with Notepad"?

Better they ruin their own soul than inflict upon others is the way to look at that.

But then, what type of people don't RTFM besides the whole generation that treat google as their manual and when the internets down, so is there `knowledge` /s.

RTFM clearly does not apply because you can't read it if you're in vim and can't exit ;)

:h or failing that, the tried and trusted :!man vim

Though I'm wondering how many have discovered the first one with some frantic help me after typing the : and got there by accident.

Oh you can apparently just hit F1 in vim, wow.

As a senior dev, I wanted to pat myself on the back and say

:q

But then I realized that the senior dev way is more like:

1. Look it up on Stack Overflow.

2. Send the Stack Oveflow to the intern and tell intern to do it.

3. Reject the PR because it lacks unit tests.

4. Reject the PR because it didn't account for an obscure case that product usually is concerned about.

5. Reject the PR because it there's a simpler way to do it.

6. Pair program with the intern because they're having trouble.

7. Realize that tests are a bit overkill, the obscure case can't happen, and the complexity is because of trying to make it testable and handling the obscure case.

8. Merge a PR that looks suspiciously like what the intern originally submitted.

9. When QA rejects, send back to QA asking for steps to reproduce (har har).

10. When QA sends back steps to reproduce, send back saying you can't reproduce (har har).

11. Sit with QA and see that the bug exists, because they doing something you didn't think of.

12. Fix the bug, merge the code.

13. When the manager asks you to, create the story in Pivotal and push it through all the states (everything so far happened in Slack).

14. Years later, come across the same problem at a different company, and notice someone `:q` in one of the side comments on Stack Overflow, which was there the last time you looked, you didn't notice it.

I do not like the grep -v grep pattern. I think the regexp trick should be prefered:

    :!ps axuw | grep [v]im | awk '{print $2}' | xargs kill -9

This can also be merged in the awk command:

    :!ps axuw | awk '/[v]im/{print $2}' | xargs kill -9

Ugh, ps|grep is unnecessary. Just use pgrep! Or even better, pkill -9 ;-)

pgrep is a good habit, it's on every major unix except perhaps aix.

Most other constructions can backfire in some unexpected way.

Next you'll be telling people to use SIGHUP instead of SIGKILL. Or to use the PID. Or to get VIM to substitute its own PID into the ex command using getpid().

* https://mywiki.wooledge.org/ProcessManagement#The_risk_of_pa...

Issue 26 (q.v.) is closed.

I started using Linux in 1997 and just today I've found out about pgrep and, on reddit, sudo !!

What a day!

Wow! Glad to be part of your journey in discovering linux.

I have been amazed by linux since my teenager years and it still has so much more to offer.

May we be blessed to be amazed for the eternities of our mortal lives.

The UNIX ecosystem (digisystem?) always has more to find.

Also, your reply is the kindest comment I've ever seen on HN.

I distinctly remember being a teenager and trying vim. Being entirely confused I wanted to exit and when I realized I couldn't I panicked a bit and started smashing keys. Eventually I gave up and forced a reboot with the power button. Based on my extensive experience with Windows I was confident it was hung in a bad state.

I came into this with a sense of "oh not again" and came out surprisingly happy. TIL that ZZ, ZQ exist and that a disown command exist on the command line.

Also my preferred method from the list is the timeout, it would be nice to have counter in a corner of the vim window to know how much time is left though.

What I do is I set a 25 min timeout, so not only it exits vim it also acts as a Pomodoro timer for me. Two birds, one stone.

I was on a remote system and remember I couldn't exit vi. What did I do? Well, I opened a second ssh session, looked up the process id with ps and killed it.

This is so many decades ago ... like the very beginning of my curiosity when it comes to IT basically. Thinking back to it, I wonder how I was able to use ssh and tools like grep, ps and kill but did not know how to operate basic vi ...

I did similar with early desktop Linux. vim opened up in one of the ttys, and I couldn't figure out how to close it, so I hopped to another tty and killed it.

>Thinking back to it, I wonder how I was able to use ssh and tools like grep, ps and kill but did not know how to operate basic vi ...

This has become a recurring thing for me to the point where I sometimes feel like I'm not as intelligent as I used to be. I'll need to look at requirements around older existing code, so I use git blame to see the commit history. It occasionally leads to me to some older code that I had written, and sometimes I marvel at how I was able to figure out or troubleshoot the issue.

One of the earliest examples in my professional career is using Threads. I had an academic understanding of threads. My practical knowledge around them was dubious at best. With the help of Stack Overflow and lots of web searching, I cobbled together a thread manager that can spawn separate threads for asynchronous web requests and kill a web request after X amount of time. I even made sure that error handling redirected gracefully should one of those threads get killed. That code (with no changes to the core functionality) still exists to this day.

They forgot the Freshman CS student way: Panic, Lock the computer in the computer room, run.

Send a PR!

This is as good of a place as any to mention that I built https://howtoquitvim.com a while back if you need a less-sadistic reminder for how to exit Everybody's Favorite Text Editor.

I have the feeling something is missing on that list, but I can't put my finger on it ...

I think it's the Hulk way. I seriously considered the Hulk way the first time.

(since then I implemented the preemptive way: never ever try to open it again)

BRS, that old classic Big Red Switch, kills all known operating systems and proc's, dead in their tracks.

Me, It's usually :wq, or sometimes :q! or more than likely ZZ - which can be done with shift zz or if you truly want to do it with just one finger, capslock then zz.

Thank you. I swear every time I see a tutorial where someone is using vim they say to save and close with :wq and it drives me nuts.

That is because it is easier to teach as x you will associate with exit, though wq is write quite, but more so if you just want to save without exit you logically understand to just use w and from that you start to think - could I do :q, why yes you can if nothing changed and if so it will tell you.

But stressing how people exit vi is like stressing about people's fashion, just not worth it. If anything, have a private laugh at them to yourself and use that to remove other stress as more than enough stress in life, more so IT without seeking it out.

I never use :wq because I obsessively save after every thought.

If exiting vim is too easy, try the advanced level: exiting "vim -y".

Wow, that's an evil mode. Man says it's the "easy" mode.

Try Ctrl-o followed by :q!

That should do it. ;)

Ctrl-o moves from INSERT mode to COMMAND mode for one command and so it still works in "easy" mode. I notice that "easy" mode was one of the things that the Nvim guys removed.

I like

which effectively does an :wq if there have been changes but is one character less.

It also prevents the modification time from being changed after closing the file, if no changes were made.

From the readme: "Remotely:

$ while true; do curl http://vi-host:8888/kill-vi-$RANDOM; done vi will eventually exit"

Bold claim, and how would you know? What if there is a network partition preventing you from getting the message that exiting vi failed and Chuck Norris?

Ah, the famous CEVP Theorem (Consistently Exiting Vim under Partition).

Almost as important a problem in Computer Science as P!=:WQ.

I got one: stop paying the electric bill.

I just installed a Kasa TP-Link smart plug, now I can kill Vim from an app!

Interestingly, deleting the vim executable won't exit, because Unix has the "funny" habit of keeping a file handle alive as long as it's referenced by a process. Really cool way to mess with some noobs.

What is the 'deleting an executable' you speak of?

All I know how to do is remove a reference to a file, and hope it's the last one and that Unix will garbage collect it eventually.

Remember kids: `rm` is just `ln` backwards.

After I invent time travel I'm going to mail my 30-years-ago self a T-shirt that says "Colon Q Bang" on the front and "You're Welcome" on the back. It will save myself much anguish.

I can't wait for this article to be on top of Google's search results for 'how to exit vim' = D

The Scrum manager way

1. Call in a meeting, early in the morning

2. Tell everybody what a good job they are doing.

3. Tell everybody that there is still a lot to do.

4. Tell everybody that "we" can do it.

5. Remind them of the importance of team work.

6. Go through the tickets.

7. Tell the project manager that a ticket for closing Vim is missing.

8. Write a ticket called "As a user I want to exit Vim!" on your own.

8.1. While reminding everybody that this is not the proper process.

9. Discuss new ticket in group.

10. Reword ticket as "As a user I want to be able to open other applications!"

11. Ask who of the team wants to do this.

12. Postpone decision until the next meeting.

There is a step somewhere in there where we waste 30 minutes playing "agile poker" and arguing about the number of story points required to close vim.

The whole thing is followed up with a two hour retrospective where we pat ourselves on the back for increasing velocity (due to assigning story points to closing vim).

Bonus points if you then are asked to map that back to actual hours so we can estimate completely unrelated future tasks while simultaneously remembering that we don't estimate in hours.

It saddens me to say, but this is so familiar. Especially working in a big corporate company where they hire scrum masters who just follow the scrum guide.

Scrum has a built in self destruct method - the retrospective. With a little maneuvering, the team should be able to remove most of the annoying things about scrum by using the retrospective. Obviously you can't go scorched earth and drop all the annoying bits at once. But, if scrum is really being followed (I know this is also part of the problem), the retro should allow the team to change the process over time.

This obviously only works when your scrum master is willing to take feedback on scrum processes. Which, with most scrum masters is not the case, you’re essentially telling them they’re doing a bad job, and it usually hurts their ego.

Something is seriously wrong if the Scrum master doesn't take feedback. That goes against the Agile values and principles.

I honestly haven't met many scrum masters who don't just preach the scrum guide. Even if the team is struggling with the way we do Agile, the scrum master will just continue to force the scrum guide onto the team.

What I currently see is that our scrum master has sold the business on the agile way, so if a developer complains about it, there's something wrong with the developer. It's probably just a bad scrum master, but I've met multiple of those.

I found that, being a special time set aside specifically for team arguments about how many angels can dance on the head of a pin, the retrospective tends to produce a much more literal version of self-destruction.

I showed up long after they implemented it, so I'm not sure how they got there, but the most well-functioning Scrum team I ever participated in had effectively designated the nominal Scrum Master as a BDFL. The retrospective then became a shorter sort of town hall meeting where everyone aired their opinions, but, since we had a BDFL, we had no need to burn energy on consensus-building. Sadly, things quickly went to hell after she left and the team reverted to a more traditional consensus-oriented approach.

You can't remove a professional scrum-master who does nothing else in the retrospective as the scrum-master is running the retrospective.

Exactly, and those scrum-masters are usually good at talking and getting the business on their sides. There's literally no way to change those processes without making yourself look bad.

Disagree: the team owns the retrospective, not the Scrum master. If team members aren't happy with what the Scrum master is doing, that should be addressed in the retrospective.

And this is coming from your own personal experience? I've never been in a scrum team where we as developers had any say in what the scrum master was doing. The most we could do was retrospectives with other developers, and try to improve there. However that's rarely enough to make a business work.

I would not call it self destruct, rather reconstruct or adjust. If the way the team uses Scrum isn't effective, then the retrospective can be used to explore issues and adjust the way of working.

You forgot the conversation on the way back from the retrospective about how velocity is a bullshit indicator of actual productivity and we aren't doing agile correctly at this company.

10.5 create a deadline

13. Ask the team what we can do to make sure we don't have to miss the deadline

14. Move the deadline 2 months in the future.

Don't you need a definition of "done"?

User is able to exit VIM by throwing their laptop out the window and vacationing to Cancun.

Can we also have some sort of a scrumish gathering, ASAP, to declare the correct use of the word "definition", because sometimes it seems we use this word arbitrarily.

As an Emacs user I just realized to my horror that I know the command(s) to exit vim but not the one(s) to exit Emacs. I can only tell you it begins with C-x. (Of course, my left hand knows.)

Sometimes your right brain doesn't have to know what your left hand is doing.

I would love to see a HowToBasic way (https://en.wikipedia.org/wiki/HowToBasic).

I once found a system where a third party vendor installed vim as root with suid permissions. I've had a few days of fun before I finally decided to clue the sysadmin about it.

In Julia slack, when talking about Julia IDEs, this came. The solution : a hardware VIM kill switch https://github.com/caseykneale/VIMKiller/blob/master/README.... I strongly suggest donating the suggested amount to the project

What about querying how much ram you have and then pasting the letter 'q' that many times plus one into the buffer?

Edit: perhaps to speed it up: start with a single 'q', selecting all, yank, and paste. Just script it to repeat until exit happens. No ram query needed.

I like The timeout way :-)

vimperil

Actually the random timeout is even better!

As I sit here, vim running for several months inside an nvim terminal inside a tmux window inside an iterm tab inside mac os x, I think the real question is, why exit vim yourself when you can Inception vim's creator to do it for you?

That, as many people know, is actually how vim finally became threaded, and I'm sure it could be used to make a code change that exits vim automatically. Then you only have the task of modifying your vim executable in memory as well as on disk, which is so trivial that I leave it as an exercise to the reader.

The Russian Roulette timeout way brings back memories of Windows 98.

I just don't understand why anyone would want to exit vim.

I thought it was a joke article until I realized it wasn't

WARNING: Learning to exit Vim is the number one gateway drug to perpetual configuration of dotfiles and plugins. The truth is that you can never exit Vim. NEVER!

I'm curious about this one:

  Don't run this, it could break your computer.

  :!echo b | sudo tee -a /proc/sysrq-trigger

Why would that break my computer?

Doesn't that just force a reboot without unmounting disks, or about the same thing that would happen if you pull the power cord (but probably safer, since anything in a hard drive write cache (or in the middle of being written to an SSD) will still be written)

Open issue #46 deals with power cords, and thus: no.

Didn't see a mention of a very fast way of exiting Vim, so sharing:

'The iTerm way': map cmd-l to send a hex code '0x6A 0x6B 0x3A 0x71 0x0D' (translates to jk:q<enter>, where jk is my Vim binding to get out of insert mode)

For me, just like any other touch typer, left thumb is always on cmd and right ring finger is always on 'l' key, so this arrangement takes least amount of time for me to quit Vim.

The only vi command I know is :q!

(That and the Rogue navigation keys.)

Bonus geezer points for calling them Rogue navigation keys instead of NetHack navigation keys.

If my ageing memory serves, it was the other way around: Rogue imitated vi for navigation keys.

Don't both originate from the fact that (some) early keyboards had the arrow keys on HJKL?

https://stackoverflow.com/a/29243081/1891877

This is a well studied problem from the days of Turing. Named slightly differently as the Halting Problem, the question of whether Vim will stop for a given arbitrary input has been proven by Turing [https://en.m.wikipedia.org/wiki/Halting_problem] to be unsolvable.

The funniest one is the "experienced product manager way" IMO. I've seen plenty of those "experienced project managers" work, and the description is spot on. It's amazing that such impediment to productivity is even tolerated, let alone paid handsome amounts of money for. All while the company _thinks_ they're getting better productivity.

I used to believe the most important scientific problems have yet to be solved, but this really was the last great mystery out there.

Favorite vim commands:

yy - yank dd - delete and yank O - insert line above o - insert line below GG - go to bottom of file gg - go to top of file Navigation keys == - auto indent code block v - visual mode :%s/find/replace/g :set paste :set number :set nonumber :q - quit :-p

I <3 vim + tmux + iTerm2 + tmuxinator

What's the best way to generate a random string in 2020??

Tell a room full of comp100 students to save and exit vim :)

Fun read! My next bash exercise will be to try and understand some of these commands, quite a feat! greping the ps output would work with any program, right ? That was pretty cool. Killing it from emacs was def a good laugh !

They should add the script kiddie way: `sudo rm -rf /` ^^

That might delete the executable but the process would still be running.

Yep, `ps | grep` is a common and useful idiom!

In fact "pkill init" or "kill 0" (each with sudo/root privileges executed) will most likely kill all processes and is some kind of process equivalent to delete all files ;-)

safe-rm voids that command ( https://launchpad.net/safe-rm )

As before, I'll see all of those and raise you killing the entire virtual machine in order to exit nano.

* https://unix.stackexchange.com/q/412194/5132

Atleast this ones a bit amusing. Speaking of amusing, this book on the vim website - https://www.vim.org/images/exiting_vim.jpg

If you use `kill -9` to exit vim, you might find your terminal in a weird state, because they are most likely using the `atexit` function to reset your termios settings to normal, but that doesn't happen if you `kill -9` it.

This post is perfect to spot people who comment without reading the source. :q

Several comments here have merely duplicated old closed issues.

* https://github.com/hakluke/how-to-exit-vim/issues/14

Ctrl+z and then kill %1 has yet to fail me. And I'm not talking just vim.

I think this is probably far too nice, but what about

    pkill vim

That just types ll vim

I think the more interesting question is, after you eventually exit vim, what do you do next?

The best advice I ever received was, you next open emacs and leave the session running the rest of your life.

Are you using tabs as well?

This is so fun. Reminds me of Nocode[0]

[0] https://github.com/kelseyhightower/nocode

I like this commit: https://github.com/kelseyhightower/nocode/commit/80f38e0f103...

It appears that the first bunch of methods don't account for graphical distributions of Vim, e.g. MacVim―which have a different executable name.

I suggest going to https://github.com/hakluke/how-to-exit-vim/issues and filing a bug report that sometimes one needs to type in a Scottish accent.

On a saved buffer, I usually use `Ctrl-w q` (Window command, close). I have Ctrl mapped to caps lock, so this is super quick to do with one hand.

Just stay in Vim :)

You could send a PR with an “Acceptance way”. Also there’s “Radical acceptance way”: kill every other process, although I’m from mobile and too lazy to work out an exact shell command for that

https://howtoexitthevimeditor.com/

Easiest way for me is ESC (just to be sure we are not in insert mode), followed by `ZZ`. (`ZQ` if you don't want to save)

The 1st example could be simpler using pgrep and cut, or simply pkill or killall.

You can also just suspend it (ctrl+Z), and resume it with fg.

I know this is a joke but my actual preferred way is :cq so that whatever thing decided to open vim doesn't proceed. :)

I know this is humor, but I never knew about using Ctrl+R (<C-r>) within insert mode or within an Ex command.

Do we know if exiting vim is solvable in all cases, or would that require some deeper result like solving P = NP?

Just close the terminal window en delete all files starting with ~ in the directory. Very clean way to stop Vim.

I just do ZZ, if I want to save the buffer, or ZQ if I was just looking, or I messed up (I'm a vim newbie).

This page is satire. :)

I would add a Paul Simon way, loading "50 Ways To Leave Your Lover" until resources are exhausted.

The BRLTTY way: 1. $ echo ZZ | brltty-clip -r 2. Switch to Vim and invoke the paste command of BRLTTY.

Aww, the first thing that came to mind for me was pkill -9 vim, which sadly isn't on the list!

I was able to find how to exit vim fairly easily. I do like this though it's quite funny.

I haven't tried any of these, but wouldn't most of them leave the .swp file there?

`ZQ` in normal mode exists VIM with no trouble. 2 keystrokes compared to `:q<Enter>`

Edit - Related in that I used vim and probably won't again:

I recently did an interview where I had to implement something to flatten a deeply nested structure into a map of path -> value.

The interviewee's had me use VIM. That was my first real dive into it. Solved the problem, already forget how to use VIM. :)

How to exit vim big brain style with all changes saved in memory.
:q!

your memory, not the computer's

This one is the shortest way in the list :

The test driven development way

:echom test_null_list()

And it works. Just checked.

Doesn't work for me, just gives an error message "E730: Using List as a String" and returns me to command mode.

That list is incomplete, at least in windows. You always can do ALT-F4

Every time I open vim by accident, I have to restart my computer.

I just wish i could upvote this more! :) Love the Jira way!

I am upset that they're using signal 9 instead of 15.

Due to the Stockholm Syndrome people started liking VIM...

Learned shift zz after four years of vimming...shame...

Maybe don’t do the reboot way on Solaris...

Recent versions of vim have a "quick" exit with mnemonic "q":

    <Esc> :q!

one could use emacs instead - it's a sure way to exit vim ... :\ :/

Obligatory

https://github.com/cabellwg/exit-vim

Next level: how to exit ed.

pssh.. they didn't mention the vimtectualist way - :q!

or the French way - ZZ

create a pull request

the french way :D

These would ruin the joke.

yeah, I was poking at the joke :)

As a vim noob, I needed to look it up [0]. ZZ saves the current file if modified and closes it. ZQ closes it without saving. Thank you, that will save me a few seconds per year.

Why the French way? I don't get it and I am very curious :-)

[0] https://unix.stackexchange.com/questions/93144/exit-vim-more...

Maybe because of our (I very much include myself) infamous inability to pronounce correctly the sound "th" and making it sound like "z" instead.

Ah yes, zis is it. Fank you.

I'd have thought it's because the French keyboard layout is arranged with the "Z" in place of the "W" on a qwerty layout

(Wild guess) If you pronounce the command aloud - "Zee-zee" - it translates to "Willy" (penis word used by children) in French. Easy mnemonic.

>Zee-zee

Only if you're American. Otherwise: "zed-zed". :)

> or the French way - ZZ

HOW DID I NOT KNOW THIS

People explained that it was [Shift] and [Z], which of course for you would have produced a lowercase 'z'.

lol

took me a while to get it

Thank you for this..

Why is :wq so hard?

Use nvim, press Ctrl-C and it will show the corresponding help message

It is not necessary to use nvim to see this help message; it's in vim 8.0 that comes stock with my Mac.

True, I just checked, though the help message is a bit different

Where's fun in that?

The one thing I remembered from school about vi was:

:q!

Figured that would be useful to know in future.

The Marvel Universe way:

Hulk smash!

  shift + zz

Save and out!

some people have way too much free time.

How about the most basic? ;-) q! wq! x!

;-)

Great jokes but bad user interface design comes at a real cost.

From perspective of ASCII-only application, vim interface isn't actually bad, it just lacks discoverability. There is also a real cost to making tool beginner-friendly and it often makes sense to optimize for advanced users instead.

An interface lacking discoverability is a bad interface.

Once you learn the tool, discoverability wastes screen space and user focus. It's like training wheels, at some point you want them off or they slow you down. I'm not a vim user, I just appreciate the UI trade-offs made by its devs.

At that point, you should be able to hide the parts of its interface that you no longer need. Defaulting to an optimized, non-discoverable setup from the start is simply a bad idea.

Vim interface is copied too often for you to call it bad. It’s obviously well-loved.

No. It is quite objectively bad ui. That thousands of users cannot figure out how to do basic things is as objective as it gets.

Also that we nerds enjoy making jokes about it instead of fixing it is the reason we don't get invited to parties.

I use vim, enjoy it, and get invited to parties.

Reply on news.ycombinator.com