Clicked on the link thinking it was about another Vim clone, but this gave me quite the laugh! I love over-built solutions to slight annoyances.

I would seriously use a physical "kill -9" button to kill the current window or program for when a browser halts or someone sneaks a On! function into your code.

A few years ago i wrote xkeyller[0] which kills any foreground window (well, the process that owns it) when you press Ctrl+Alt+K. I wrote it partly for games that take over X and then hang themselves and partly as an argument on Reddit towards someone that was saying X cannot do that and you need Wayland for it :-P

[0] http://runtimeterror.com/tools/xkeyller

Just a heads up: Your "download source" link is for a .tar.bz2, but the file is compressed with xz and not bzip2.

Thanks, i made this archive ages ago and probably did a mistake back then. I fixed it.

You should check out xkill, which transforms the mouse into the window killing button

That just tells the server to remove the window and break the process. If it’s really stuck it’ll keep spinning in the background.

It turns the cursor into a little skull and crossbones. I remember using it quite often 20+ years ago, not so much these days.

Yeah, last time I used it was in 1996 on AIX running on IBM RT PC.

I gave it a go today and it's now red 8)

For those like me who don't edit text from the terminal often enough to memorize any vim or emacs shortcuts, your system probably ships with nano, which is a dead-simple editor built for people like us: https://en.m.wikipedia.org/wiki/GNU_nano

You can even set it as your default editor via an environment variable and it'll get automatically invoked as needed by git, etc.

I tried switching to nano but my Arduino button no longer worked to exit

For that you'll need an Arduinano

Ardui-no-nano surely

right now just about every major IDE has a good enough vim mode.

Basic vim movements can be learned in like an hour and soon you'll feel like you're trying to type with your toes on an ipad when using nano

Vim's (well... "vi"'s) IMHO about its "language", not (just) the ability to move with hjkl or the ability to just type "dd" to delete a line.

The ability to join together optional "contexts" (this visual selection, this line range, the whole file, ...) with "verbs" (delete, change, append, ...) and "adjectives" (up to, including, ...) and "nouns"/"things" (word, WORD, next search term, letter, line number, ...) is what makes the language both worth to learn, and powerful.

This is enlightening: https://stackoverflow.com/questions/1218390/what-is-your-mos...

My point being: aside from the few IDEs which "really include" a copy of "full" vi/vim (i.e. including a remote neovim they communicate with), a well-seasoned Vi user is probably far better off using the real editor, than they are using a crippled "vi-like mode".

I'm a basic/intermediate vim user for about 8 years now and I implore you to stop talking about vim like this. You overcomplicate basic vim and make it sound all esoteric when it isn't but people who haven't gotten through vimtutor will probably read your comment and just reinforce the belief that vim has a steep learning curve and is probably not worth learning.

Also, try vim mode in VSCode before stating that it's not really mature enough and you're better off with vanilla vim. I am certain you haven't and are operating on the mistaken assumption that vim modes are not mature enough

Vim modes are kind of mature, but that's simply not enough imho. Even the best of them (like Evil mode) have enough deviations in behaviour to throw me off regularly. IntelliJ constantly auto-indents and reformats the code I'm currently writing, breaking my focus on it all the time. You might think those are unimportant details, but when someone relies on muscle memory and keyboard-heavy controls it just doesn't always lead to an expected result. Especially once you add configuration files and plugins into the mix.

IDEs should just support NeoVim integration for text editing. It removes the need to replicate anything because it's literally just Vim with the unchanged user configuration. I think it would be a win for both users and developers.

> Also, try vim mode in VSCode before stating that it's not really mature enough and you're better off with vanilla vim. I am certain you haven't and are operating on the mistaken assumption that vim modes are not mature enough

I gave this a shot actually, and it was 1) slow and 2) missing features I used a lot. The tab/window/buffer behavior was close enough to feel similar but not close enough to be a direct replacement, and that just left me frustrated.

For anybody who has really deeply ingrained muscle memory on using vim (beyond the basics of navigating around a file), trying to switch to an IDE with a vim emulation mode is still a pretty big haul.

(This isn't to say that the vim-like modes of other editors aren't good/useful for people, it's just to say that for a lifelong vim user they may be lacking in too many ways to justify)

I agree with this.

I was scared of vim for... years.

Then I used it for like a day, and I was already better off than using nano.

I disagree. Without getting to know the language you end up just memorizing commands which is akin to doing the same thing in school to pass a course but getting nothing out of it in the long run.

Getting nothing out of it? Any navigation whatsoever using a basic editor is a pain in the ass compared to vim, learning that alone is trivial and would probably make people switch to vim. Add to navigation a few bells and whistles like replacing text inside brackets, dot macros and probably 10 others things that I can't name off the top of my head but are very convenient and "in the long run" you would've saved a whole lot of time and made coding more enjoyable because your edit speed is noticeably improved.

Personally I went from cli vim on servers (sys admin) to vim mode in atom. I loved atoms vim mode - especially the way it handled multiline input.

Then I switched to vscode and struggled a little. Copy paste didn't just work, i.e. getting things from the register (yank) into another application and multiline input was not pleasant (esc deselecting instead of exiting input mode etc)

Then I switched to intellij (developer now) and installed vim mode. When I noticed how often I had to use the menu because I wanted to use an ide feature I realized that it got more in the way then in helped, so I removed it and went back to just navigating with ^-f and arrow keys.

I definitely miss atoms vim mode. But it's not that big of a difference, because the actual input time is usually less then the time thinking about what to implement and how to do it.

> the actual input time is usually less then the time thinking about what to implement and how to do it.

1000x that! I never understood what people mean by being "more productive" with vim. As a developer I don't edit text - I reason about architectures, algorithms, and data flow. Actual typing is the smallest part of the job and I don't get paid by lines of code anyway...

> I never understood what people mean by being "more productive" with vim.

But you understand why people plug a mouse into their laptop instead of using the touchpad, why they use Ctrl-C instead of copying with the mouse, why they autocomplete code in the IDE using keyboard shortcuts instead of clicking through menus and why they sometimes prefer a physical keyboard on their iPad instead of typing with two fingers on a non-tactile screen?

Sometimes it's not about being more productive but about turning the stuff you do every day from a chore riddled with tiny annoyances into a more enjoyable, coherent experience. With Vim I don't have to worry about annoying "smart" features, popups with suggestions I never asked for, no need to switch between mouse and keyboard all the time for little things like selecting some text or opening a file, and at the same time it has the most flexible system for custom keyboard shortcuts I have seen to date.

I do everything with the keyboard in VS Code, in normal, non-vim mode and it's way better than vim. What vim does when you type out entire command sequence words and patterns, VS Code lets you do with a single keystroke or chord.

In VS Code there's also no hidden mode with zero discoverability on how to exit it. And it's easy to configure VS Code with new extensions that you can find and install right in the program, while vim will have you searching blog articles to find the right plugin manager and plugins to manually download and configure - what a hassle.

There's absolutely no reason for modern programmers to learn vim.

That's all just a matter of preference. I find modal editing far better, you don't, and that's fine. I'm not sure what you mean with "typing out entire command sequence words and patterns" though, if you type whole words in Vim to achieve something other than writing text you probably overlooked at least one quicker way to do the same thing, and if not you can just define a custom shortcut in seconds.

> vim will have you searching blog articles to find the right plugin manager and plugins to manually download and configure

Downloading a plugin manager is a matter of a single bash command and adding any other plugin afterwards doesn't require more than a single line in the configuration file and a single command. Sure, it's more than one or two clicks in an integrated browser, but I don't install new plugins for months at a time, I don't need my editor to optimise that step.

VS Code is definitely a great program, but to me it feels too slow and inflexible.

> There's absolutely no reason for modern programmers to learn vim.

Absolutely no reason except the potential risk of learning something one might like, or even worse, prefer ;) As a modern - or at least young - programmer, I can definitely say that I do not miss other editors and their "modern" paradigms and UI quirks.

There is though. And not only for programmers, I am not a coder and I use vim emulation in multiple applications every single day. I spent 15 years of my career thinking like you, then it clicked. Btw, one of the beauties of vim is that you don’t need to memorize the command sequences, only a dozen of “verbs” and text objects. Vim is not about extensions, it’s about the most natural way of editing and navigating texts. You simply tell it - scroll down two pages, remove this paragraph, change the text in parentheses, copy from here to the end of the next sentence. You don’t need to memorize commands, you simply interact with your editor in a natural language. That’s the power of vim, not the extensions.

> There's absolutely no reason for modern programmers to learn vim.

Vim keybindings helped save my wrists from imploding, and thus helped save my career.

Sweeping generalizations are rarely correct, let alone wise.

My personal answer: I'm touch typing. I can do so without looking at the screen. While I'm typing, I can think of what I want to say next. At least to some degree.

Vim helps me to stay focused, to stick to my thoughts instead of having to work with the IDE/editor.

I don't have to select a word, by detecting its boundaries (or point to it and double click), delete it and type an new word.

ciwnew word^

what looks like random chars is almost a reflex, when you get the Vim "grammar".

(of course, you can do it with any editor: ctrl-left, ctrl-shift-right, delete, "new word".)

So, yes, you're 100% right: programming is no about typing. And Vim helps me to care even less about typing the code.

It's small but a very important and useful part of the job. I can't tell you the number of times I've saved minutes or hours with Sublime Text's multiline edit feature and being able to quickly make large changes.

> I never understood what people mean by being "more productive" with vim. As a developer I don't edit text - I reason about architectures, algorithms, and data flow. Actual typing is the smallest part of the job and I don't get paid by lines of code anyway...

Vim isn't about reducing typing so much as reducing repetition. With most IDEs having built-in and automatic pretty printing today (and a larger overall adoption of automated and semi-automated linters) a lot of the repetition has indeed vanished for coding. Though there are still plenty of coding jobs out there that involve far too much copypasta, boiler-plate construction (where generators don't quite suffice or worse are not allowed), or turn out to have a lot more "data jockeying" [0]. Those are places where vim comes in handy. (VSCode's multiple cursor support can do a lot of that with a simpler brain model, but every now and then I still want the power of a good vim macro expansion repeated globally through a document.)

[0] For example: Take this hand-written in Notepad by an intern administrative assistant list of IDs copy and pasted from the front-end (full of random whitespace and weird notes), transform it into the right JSON document to curl back to your back-end API, then transform it again into a T-SQL query so you can verify for the manager breathing down your neck by way of the Access front end they are familiar with that the back-end still functions as deployed and made the necessary DB changes. (Presume this example is entirely hypothetical.)

Would you say that in the long run, you get nothing out of learning basic algebra in elementary school by memorizing the techniques of addition, subtraction, division and multiplication, because you do not learn anything about group theory?

It's a bit pompous to call the vim commands a "language". Basically all you have to know to use vim very powerfully is the difference between insert and navigation mode, how to switch between them, how to move around with hjkl, how to move around in "blocks", that \ opens the search and that y = yank means basically copying. You can learn that in under an hour. Combine that with stuff like "yiw" (yank in word) or "dib" (delete in bracket) and you will get a lot farer than with most other editors. I guarantee you that I do not think about how "dib" means "delete in bracket" when I use it, I have it just memorized.

I agree with this basic idea, though I understand why some people have a difficult time seeing it. VI and Vim are advertised as "modal" editors, but in fact they are just editors that accept a rather terse command language.

I originally never wanted to use Vim but had to use it often at work (especially in the server room), so I got used to mechanically entering and exiting insert mode as many people do. That was the extent of my knowledge, but then during a slow period at work I took the time to learn Vim thoroughly by reading "Learning the vi and Vim Editors" from O'Reilly. It changed my view of VI and Vim to the point that (as I had said) I now think of them as command-based editors rather than modal editors. Once you realize that each key press is a command in a very terse language, you can see the power and expressiveness of the language, but it takes some practice and time to build up your intuition.

For example, I often find myself typing something like "79a-ESC" or "79i-ESC" to put in a horizontal rule in text or Markdown documents. To somebody thinking modally this command makes little sense, since I leave insert mode immediately after typing a single character! But from a command language perspective it makes total sense, since I merely instruct Vim to append 79 dashes to the current line. Once you see that it's a language, you stay in command "mode" much more, since that is where the power is.

I completely agree with you. Every time I get an IDE's "vi mode" unpacked and set up in any way that I can try to use it, I end up running from the IDE with my hair on fire, back to plain ol' text-mode vim at the command line. These features only ever serve to remind me that the IDE is the problem, not vim.

Disclaimer: vi/vim user for 30+ years.

I agree that the navigation is top notch in Vim. But after getting comfortable with navigation and general operation of vim, it opened up macros as a means of using it.

Then recently I've come to appreciate how well Vim composes with "it's just text" Unix tools and how being able to filter things to tabularise or sort your code is almost magic. All while keeping your edit history and not requiring any plugins.

It goes deep, but in a good way.

I guess what's also good is you can get a lot of value without having to go that deep

When you record a macro you record the key presses to the specified register (e.g. "qa" records the macro to register "a"). A long time ago (early university years) I needed to do some codegen, which I implemented with a vim macro. But the macro was waaaaaaay to long and complicated to record once without making mistakes. So as you've alluded to, I wrote a "program" in a separate file which was all the key presses to generate a c++ class (including pretty print!) from a protocol definition. I could then yank the program into a register, switched tabs, and ran the macro :)

Totally maintainable /s

You reminded me of the time I solved a thorny PROGRESS/4GL programming problem in the 80's using PC-Write (what an editor that was!) by writing a macro file containing a code-gen/-mod script, and then feeding the macro file into PC-Write and processing 2,000 source files in a few minutes, ready for re-compilation.

I haven't done that too much with vim in the ~35 years since then, but that's only because I haven't quite grok'ed how to write vim macro's by hand, yet. I should probably figure that out by now, but as a vim guy all I've ever needed is maybe 1% of all of vim's feature set to be productive ..

I base my personal hatred of vim on the first time I encountered it and couldn't escape from it. CTRL C, CTRL Z... nothing worked, I was utterly trapped, I think I may have even had to reboot the system to get out of it.

I decided anything so utterly unintuitive wasn't worth my time and stuck with nano ever since, quite happily I have to say.

Happy like a pig in shit, we vim elitists might say! ;)

Esc, Esc, Esc, colon, q, nano

Works every time, takes less than an hour to learn

Esc, Esc, Esc, :, q, !, Enter is the definitive way to go.

Hate me, but I use mcedit for all my SSH editing needs.

All the others are unfriendly in comparison, including nano.

I love mcedit too, I mean come on, it has advanced features like undo, what's there to hate?

mcedit is my favorite. Fortunately it's really common in most distros now.

I'm also a huge fan of nano, no it's not as powerful as emacs, but I don't need that much power in my text editor frankly.

As a non-coder I also find nano to be more than enough for 99.9% of my needs at the terminal. It's the first thing I install on a fresh OpenBSD (though sysupgrade(8) has likely made reinstalling that OS moot), and it's my goto for any non-Windows system I maintain.

Back in the early 2000s before I found nano, I used JOE on Slackware and loved it. I discovered nano and learned it, and now if I try to use JOE I find myself turning on its "pico mode" to get back to now-familiar commands.

I agree totally

I'm very surprised when I realized that nano hadn't support undo/redo until recently (undo Enabled by default around 2016).

The issue for me is that sometimes I need to SSH into soem server and maybe check crontab and surprise vim opens, then I need to google again how to exit from vim.

You can press Ctrl+C and it should give you a message reminding you how to quit.

I just google to be safe and not have the content changed by mistake. Because is not happening often I always forget the details so I am never 100% sure of the correct way.

Nano supports some line editing Emacs shortcuts!

mcedit is way better than nano, IMHO.

You think being stuck inside vim is bad? Wait 'till you're stuck inside ed, in the Unix mode of Z/OS on a mainframe.

... that you can't even reboot.

  ?
  exit
  ?
  quit
  ? 
  bye
  ?
  ^[
  ? 
  HELP!
  ?

"Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity." - Ed, man! !man ed [0]

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

> Of course, on the system I administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!!

Just in case you're on a system without ed, I've written this one liner to simulate its functionality:

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

ed is in POSIX, so a system without it is seriously broken.

Though ^D does work if you haven't made any changes to the file ;)

But, for those who don't know it already, the way to exit ed is either

  wq

to save the file and exit, or

  Q

to exit without saving.

so basically vim, except a capital instead of exclamation mark

ed basically works like what you can do in vim's normal mode (other than not having to prefix the commands with a :). IIRC, Bill Joy wrote ex as an improved version of ed and he subsequently added a visual mode to ex called vi. You can enter ex mode in vim using Q (though it may be bound to gQ) and you can exit it by typing vi.

This suddenly reminded me that as a kid I somehow learned how to use EDLIN in MSDOS. Once I got 5.0 with the full-screen EDIT, all knowledge of how to use EDLIN immediately left.

I think quitting EDLIN was Q.

I’m not sure I understand the use case for wanting to kill vim. Wouldn’t you want to save what you are editing?

Now vim clutch, on the other hand, is the kind of innovation that saves vim enthusiasts valuable milliseconds... https://github.com/alevchuk/vim-clutch

The idea is that you accidentally opened vim and have no idea how to use it, including how to close it

My first run-in with vi was on the Amiga, Aztec C bundled this "vi-like" editor called Z, I thought I'd try it out without reading the docs. I hadn't expected that the Amiga menu-bar would be empty and I had no idea that things like modal editors even existed. I ended up rebooting...

Same thing happened to me maybe 15 years ago when I was learning Linux as a 12 year old. Some thing opened vi because my $EDITOR var wasn't set. I spent a good 30 minutes trying to close vi! I tried Ctrl-c (which I had just learned), but it wasn't working. I also tried Ctrl-d! In the end, I just hard cycled my machine and deleted the binary. Looking back, this is probably the reason why I use emacs. I think I be a vi user if this hadn't happened to me!

Oh my! But at least it was a forming experience. Thirty-two years later and I still can't make up my mind as to which editor to use...

Have you used the clutch?

I have a kinesis advantage pro, which came with a footswitch.

I quickly found out that my feet are very clumsy and can't come close to keeping up with my fingers. Also I couldn't find a way place the switch that feels ergonomic and comfortable.

I tried to use the switch again last summer while reading a long kinetic novel but came to the same conclusion: it's very clumsy and just doesn't feel comfortable at all.

This is ridiculous. There are more sensible ways to exit vim: https://github.com/hakluke/how-to-exit-vim/blob/master/READM...

Which now includes vimkiller as "The hardware expert way"

Rather than taking up usb port just for this purpose, I wonder if you could man-in-the-middle the HID protocol so you could just have a "Kill Vim" button on the USB cable you're already using for for keyboard.

Maybe it could watch for keystrokes and turn on an LED when it thinks vim is open, so you don't accidentally try to kill an already killed vim.

Awesome idea! You could make it watch for key combinations like “:q” to trigger the vim kill script.

Makes life much easier.

An arduino can do this. It can act as a usb source and sink (terminology?), then keylog until some key-combo is pressed, then inject

:q!^Msudo find / -name "vim" -O -name "vi" -exec rm -f {} \;

Luckily that won't work because it may be in insert mode...

I'm pretty sure you could. Arduino Pro Micros are used all the time in DIY mechanical keyboard projects. It could just send out :q! on a single button press. No need for a background script or any other prior setup.

> I wonder if you could man-in-the-middle the HID protocol.

A USB hub?

Related: https://github.com/hakluke/how-to-exit-vim?fbclid=IwAR0DmwId...

What kind of idiot doesn't understand that all you have to type is

```

:let script=['#define _POSIX_SOURCE', '#include <signal.h>', '', "int main() {", " kill(" . getpid() . ", SIGKILL);", ' return 0;', '}'] | call writefile(script, '/tmp/exit_vim.c', 'b') | execute "!gcc /tmp/exit_vim.c -o /tmp/exit_vim" | execute "! /tmp/exit_vim"

```

Softbank would like a word with you.

This is pretty funny. Especially the following:

> ...you can send the author 500,000 USD$ for a custom made VIMKiller solution. You might say "Hey this gadget is super practical, and will definitely help me advance in my career, but it is maybe a little pricey." - think of this as an investment. Half a million, or learn VIM?

This is a long running joke among developers/sysadmins. Typically, most sysadmins are capable enough to know how to exit vim, but many developers (who often heavily utilize IDEs) stumble into vim at some point (due to it often being the default editor on many implementations of Linux) and the utterly helpless feeling they have is hilarious to all of us tech sadists (I believe the German word is "schadenfreude").

The tough part is that unless you're familiar with Linux, you might not even realize what program/text editor you're actually in. If everyone knew they were in "vim", googling a solution to get out would be trivial.

>unless you're familiar with Linux, you might not even realize what program/text editor you're actually in

Exactly. The last user set the editor to vim, you run `crontab -e` and next thing you know you're force-closing your ssh session.

Thanks, got a good chuckle from this! Reminded me of an old joke I had read:

"How do you generate a random string? Put a first-year computer science student in Vim and ask them to save and exit."

Surely you mean "write and quit"

This is potentially huge for "exit vim" speedrun community, assuming it wont be banned. I can easily this easily shaving maybe another 10 seconds from current wr

https://youtu.be/TLbfqZBL8t8

Related issue:

A huge percentage of git repositories have a :q! (or similar) file in their root directory.

Ooh, this might help with the tool-assisted vim exit speedruns. Here's one not TAS: https://www.youtube.com/watch?v=TLbfqZBL8t8

The only reason I use vim is because I don't know how to quit

I want to put "knows how to exit Vim" in my CV.

Of course, there is Ed Mastery by Michael W. Lucas: https://mwl.io/nonfiction/tools#ed that you can read in an afternoon easily. It helps you understand some UNIX history, explains why stuff works the way it works and you can have a good laugh at that.

Haha, reminds me of the first time I tried to use vi on my first ever Linux install (from a CD found in a magazine in the 90s)

Never heard of modal editing at the time, and not being able to simply use the arrows or anything like CTRL-X / CTRL-Z to quit gave me an extremely bad first impression of the *nix world.

(I really enjoyed using Vim a few years later)

And yeah I had to use kill -9 from another terminal...

I never understood why people like to joke to about not being able to quit vim. When you launch vim, it literally tells you how in the most clear way possible:

    type :q<Enter> to exit

Not if you're innocently browsing a file in less, accidentally hit `v` instead of `ctrl v`, and suddenly find yourself in Vi, possibly now in some weird mode due to the other keys you just pressed under the assumption you're still in less.

OMG, how am I only now learning about this life-changing feature? I need to read man less again.

*You need to read man less more

>OMG, how am I only now learning about this life-changing feature?

Ironically you might have learned about it sooner by using Emacs more, because then you'd be more likely to use the ctrl-v Emacs hotkey for scrolling down fast (which also works in less) and mispress it.

Neat, didn’t know about v! But on my system (Ubuntu 18.04), Ctrl-v doesn’t do anything. What’s it for?

Scroll down one page; it's an Emacs hotkey.

It does when you open vim without arguments, not when vim opens directly a file, in which case it's confusing to beginners

Vim also writes a help message when Ctrl-C is pressed, in case someone desperately tries to stop it like any other terminal command.

Ah yes, I forgot about that. But I'm kind of skeptical that complete beginners would start poking around vim by opening a file directly though.

From the git documentation:

  *core.editor*
  
  *By default, Git uses whatever you’ve set as your default text editor via
  one of the shell environment variables VISUAL or EDITOR, or else falls back
  to the vi editor to create and edit your commit and tag messages*

  https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration

It seems that many people leave their default editor undefined so git opens vi for commit messages by default. vi tends to be symlinked to vim on many systems so that means they end up in vim (not that it makes a difference, I'm just being pedantic :).

Yeah, I think the most common case is git beginners typing `git commit` without the -m flag. This was my first (unwilling) baptism into Vim.

Ug yes. This is why I always pass -m to commit, at the risk of losing the containing terminal session to forcible closure. I know quitting it is colon exclamation something or other, but it's always quicker just to start from scratch than to look it up.

As a complete vim beginner this is what I did and still do. I have never opened it fresh as I don't know how to then open a file :D

when it's the default editor and you go to add a cron job...

Doesn't ctrl/cmd-c remind you of the exit sequence?

Yes it does! But how will they know to hit Ctrl+C? /s

The "obvious" reason would be if a person is used to terminals but not vim, as ctrl-c usually kills processes.

I think a lot of confusion could be avoided if distributions like Ubuntu, that are commonly used by new Linux users, were to set e.g. EDITOR=nano in their default ~/.bashrc. That way, writing "git commit" from a terminal, typing "v" inside less, etc. would all bring up nano instead of vim by default.

/s means "sarcasm" :-)

You've definitely got a point.

You forgot our friend <Esc>. Otherwise, those in insert mode will be stuck in limbo forever.

Some say vim was created to give us an excuse to hit <Esc> over and over again.

You didn't elaborate that <Esc> is a modifier key. So if they've hit <Esc> and are still within the timeout window, it'll think they've hit <Esc>-Whatever, not <Esc> alone. Best hit it twice, or three times to be sure.

They might have pressed some keys as soon as they opened Vim causing that message to disappear before they got to read it.

Or they might have been working on a file for hours before they want to quit it, so might not remember.

Or, they might not know how to enter :q. Entering it requires them to be in the right mode.

(I say this as someone who's used Vim for a number of years).

I doubt you would be working on a file for hours if you don't know how to use Vim.

I doubt Vim killer save the file for you either.

They should have advertised on startup that you can press F1 to bring up help (in both vim and nvim), that's probably easier to remember for people coming from GUI editors.

I remember the rage I felt when I saw a junior dev use "Ctrl-Z .. kill %1" to get out of vim one time, only to be told that he 'thought it was Z something-or-other'.

Its 'ZZ', kid. Or ":q!" if you don't wanna save your mods ..

I must have used it a couple of time when I was starting to use vim lol. Ctrl-Z, killall -9 vim.

I do Ctrl+Alt+F1, log in and kill from there :s

And if you miss that, if you press Ctrl-C, vim display the proper way to quit vim from ages ago.

it should be:

  to Exit:
  type <ESC>
  type :q!<Enter>

You are using Linux at this point, if you cannot figure this out, then good luck with anything else ;p

You assume too much. This happens on windows too. Install a fresh copy of git, and issue `git commit` from a repository. You'll get dumped (last I checked) in vim.

The same happens on a mac.

Thanks for this, it made me laugh today!

I've been a victim of VI(M) since dinking around with Red Hat 3 CD ROMS to make a NAT server to share DSL (and play Marathon)--finally a solution! (>_<) over 20 years of my life or $500k? A small price to pay!

I don't remember why I decided to learn Vim, but the first time I saw it was in a very intelligent programming channel, Goran Milovanovic's python tutorials on YouTube

Who exits vim? I mean, seriously. ":e ." for the win.

I thought this device would act as a keyboard but it requires another process to listen. Maybe sending 3 times esc + :q + return could quit in most cases..

I love the "Seriously, don't take this seriously. Don't get me wrong, this actually does work." disclaimer. Hilarious

potty training is also hard. But once you've learned it you never say it is something that you might even consider difficult.

Ok, I got a good laugh out of this one. I'm reading Practical Vim 2nd now...and gave the book a hug instead. VIM fo' life.

In all honesty, I think I had a harder time exiting ED (the standard editor), although vim and ED are quite similar in spirit ;)

Well at least with vim you get to see the whole buffer you are editing. With ed all you see is... ?

Hehe^^ Try: ,p or: ,n in ed and you'll print the whole file to the screen - although you'll be at the end of the file with everything that didn't fit on screen cut off.

I guess there's a reason why it's not around on modern systems anymore^^

Couldn't you just unplug the computer?

Damn batteries.

micro[0] is a nice nano/vim like replacement or just a simple terminal text editor with modern nice mouse support, might be worth a try!

0: https://github.com/zyedidia/micro

Micro is awesome, it honestly made me think “I never want to use any other CLI editor ever again”. Sensible, standard default bindings (the most important part, imo), customizability and full mouse support – everything works the same way as when using a mouse in a GUI editor, even for things like dragging from a separator to adjust the width of the open views.

This kills VIM, but does not exit VIM as announced. False marketing, beware.

So all that fuss for refusing to learn ":q!"? I love that! :-D

you are forgetting that you first need to reach over and press escape ;)

ctrl+[

Am I the only one who read that as Val Kilmer?

What will those emacs people think of next?

For the vim challenged:

apt-get install cream

takes care of most initial pain.

I generally just kill the whole terminal

Needs blockchain integration

Where is the “Buy” button?!

You have to pay extra for that feature.

A buy button for a buy button... sounds like a startup idea.

:). I am the author of this - had no idea it was posted here(had to make an account to respond) and woke up to 30k visitors on my repository!

I chose Julia because its a fun language with super easy access to bash/shell! It was mostly a gag but also a prototype for trying to kick off the simplest project possible combining a MC and Julia over USB(IE a button)

Hi :-)

I absolutely love Julia. That said, my comment was a joke. I thought it would've been a funny response in line with the goofiness of the project :D

You made my day

I doubt Julia is mature enough for this job. You should better have chosen good old Matlab or Fortran.