Helping a Million Developers Exit Vim
stackoverflow.blog
stackoverflow.blog
Does anybody remember the DEC keyboards where there was no traditional ESC key, but it was F11? (http://www.cosam.org/images/vt220/keyboard.jpg). Yeah, we used DECstations in the grad labs, and whenever a new grad student asked me a question in the 1st week, I'd answer "F11", and 90% of the time I was right.
IDE users, you're doomed to stay single!
"She badly needed an escape, and I showed her the way."
...sorry, terrible pun.
I met my wife in a physics lecture, and she credits me with her sticking with engineering, but your tale is better.
Important question: did she end up learning vi after that?
But she just didn't know that F11 was ESC on those DEC keyboards. It was labelled and all, but it was nowhere near where ESC is normally on a keyboard.
(but I guess you already asked her)
I used VT100 terminals for years on both mainframe and CP/M systems. Keyboards were not very standardized before then, the mouse did not exist and most text editors had to use all sorts of convoluted commands to allow you to do anything.
http://www.vintagecomputer.net/digital/VT100/DEC_VT100_SYSBO...
I ran the first version of AutoCAD back then on a CP/M system with 64K of RAM, an S-100 RAMDISK card, an 8087 math co-processor on yet another S-100 card, another card with a graphics co-processor and a 1K x 1K CRT-based analog display. This is the reason AutoCAD has the console. You would type the commands on your VT-100 terminal and the graphics would happen on the stand-alone display. You had to load and unload modules based on what you were doing in order to control memory consumption. AutoLISP, the version of LISP included with AutoCAD, was invaluable.
Oh, yeah, 8 inch floppies and no hard drives.
Everything worked.
I've been coding for 16 hours straight and have at least another four in front of me (have to deliver tomorrow AM) so I don't have a ton of time to answer this.
I'll use today as my example of how irrelevant (and counterproductive) vi/m can be.
I'm working on a large Django project and cranking out apps like there's no tomorrow. I use PyCharm for this.
Here's a case where experts are making it their business to deliver a superior tool that allows me to get my work done. It has myriad tools configured and configurable to help me. I don't have to futz around with weird custom stuff. It is intelligent about Python, Django, JS, jQuery, databases, HTML, packages, Git, Python console, Django console, etc. It can even talk to my servers. PyCharm is, in my opinion, a nearly unmatched productivity tool.
I lied. I am working on two large Django projects simultaneously because some of the work for the new project entails porting from an old one. So, two PyCharm windows on two 24 inch monitors and two browser instances side-by-side on the third monitor.
Can you setup vim to do some/all of the above. To some extent, yes. I haven't used it at this level in quite some time so I can't answer the question. What's the question? Can you setup vim to match PyCharm feature for feature? I don't think you can, and, if you could, it'd be a nightmare.
A lot of the vim "religion" centers around keeping your hands on the keyboard, not using the mouse, carpal tunnel and speed.
Keeping your hands on the keyboard is irrelevant unless you are a data entry clerk. If you are a software developer you are far more likely to spend more time doing things other than typing. Designing data structures, diagramming databases, researching approaches to solving a problem. Thinking.
The above is also used hand-in-hand with "vim is faster". Yeah, again, if you are a data entry clerk entering tax return records this might have some value. Software development? Nah. The time one could save by only having to move a finger a few centimeters is but a rounding error in the context of any non-trivial software development project. It's silly, really. Take the entirety of a project and multiply typing time by, I don't know, 1.25. It would still be insignificant when compared to the overall project time. Debugging alone takes orders of magnitude more time than anyone could save by typing faster.
Not using the mouse. You know, those of us who grew up using, designing, building and programming computers that did not have a mouse were ecstatic when the mouse arrived. It's just plain silly to malign the mouse. I will say that I switched to a thumb operated trackball a long time ago. I don't go looking for a mouse. My trackball is always there, quite literally touching the right edge of the keyboard. And I don't have to move it all over the place to use it.
Carpal tunnel. Serious problem. I suffered from this about fifteen years ago. Doing 18 hour days in front of the keyboard was red-hot painful. I tried different ideas. I knew people who had to have surgery on both wrists and were never again the same. I wanted to avoid that scenario.
I ultimately did two things: First, I switched to a thumb operated trackball. Mice are not designed right and you have to move all over the place all the time. This is very repetitive and not good. Second, I designed and built my own desk. I welded a steel framework that supported a surface for the monitors at 29 inches off the floor. The framework also had a full length shelf in the front with the surface dropped down about three inches. The front of that shelf had a 2 inch raised lip. So, my forearms rested on this lip and my keyboard and trackball were two inches below that. My hands naturally drooped into that cavity. No more carpal tunnel. Being in front of the computer doing everything from mechanical to electrical to software engineering using various interfaces for 16+ hours is normal for me. I have not had any issues in 15 years or so. None.
All of the arguments for vim are simply irrelevant. The only argument I could find for knowing how to use it at a basic to mid level is this: If you find yourself having to access a remote system with a computer that dates back to the stone age you might have no choice but to have to edit files remotely and you know that vim/vi will be on that system. Personally, I have never in over thirty years had that problem. These days I'll use something like CuteFTP if I have to or, as I said above, PyCharm and other IDE's (PHPStorm, etc.) know how to talk to servers and allow remote editing "in comfort". I mean, you can buy a $200 PC laptop with a large 17 inch screen, full keyboard, etc. these days. No more excuses.
Bottom line: vi/vim don't make sense because they do not provide any advantages when compared to state of the art IDE's.
Wow, I ended up typing more than I wanted to. Oh well.
For me the main advantage of vi/vim is that I don't have to learn new editing keybindings each time I change editor/IDE. Vim mode is probably there and the rest I can rebind.
Another advantage for Vim/Emacs, especially Emacs, is that they are very extensible so you can actually have features that are more cutting-edge than what commercial IDEs have yet. Still I do think that the IDE package is more productive.
I only use a mouse when I use many monitors (3+) and the desktop surface area is significant. In all other cases I prefer to use a very customized touchpad setup. I use a business laptop because it has buttons for the touchpad both below and above the touchpad(the buttons for the trackpoint. And I configured it so that all the buttons below are the normal click and a button above is the secondary click. And I disabled tapping because tapping gives you no feedback and prevent you from resting your hand on the touchpad. The main reason I switched is because I find scrolling on a touchpad (either 2 finger scrolling for short distances or circular scrolling for longer distances) a lot more comfortable than the scroll wheel. Scrolling a lot using a scroll wheel makes my middle finger hurt and middle click auto-scrolling doesn't work everywhere.
This means I can mouse around using either hand in the same way. Most touch pads are configured with buttons (reals or virtual) in the bottom left and right sides for left and right click. This means using the touchpad is different for the left hand than it is for the right hand.
The only other touchpad I found as usable was the Apple trackpad when it still had a button. I clicked with the button and the difference between primary and secondary click was whether I had two fingers on the trackpad.
I mostly agree with you, but I think there is value in fast text editing for software development. The advantage of being able to edit code quickly is that typing doesn't interrupt your train of thought as much.
Forget IDE's for a moment. Look at an editor like Atom. It's fantastic. You type "for" and it expands the for loop automatically for you and it understands languages. And, more importantly, you have to spend exactly zero minutes configuring that behavior.
Let professionals make great IDE's and tools. Focus on the real job in software development, which is not being a text entry machine.
On of these days I may try my hand at building something like that (assuming nobody beats me to it, which would be even better).
That's a nice side effect, but it's not why vim is "better".
"Normal mode" in vim ties composeable functions each to a separate key. The "." key repeats the most recent function. You can record a string of keystrokes to a macro, and even edit it as plain text.
Vim is fantastic for editing text, which is 99% of what most of us do. It may not be your first choice for creation (although it is mine), but that doesn't make it worthless.
I challenge anyone to prove that a non-trivial project, say, a year of work for a team of five developers, would get done any faster, better and with less bugs because of the single act of adopting vim vs. a top grade IDE.
That's entirely my point. It's not about efficiency. It's a lot like using an alternative keyboard layout. Sure, it isn't faster, but it's a lot more comfortable.
Vim is great for editing text. There are functions that can easily be used to accomplish the editing task you want to do. Having tools designed for the task at hand makes working easier, and more comfortable. It's akin to having more leverage.
> It was designed to deal with shitty keyboards of the time. And now it is a cult.
That's very true. Like many other projects, with age Vim has held to tightly onto tradition. The functions available in normal mode are the same functions bound to the same keys. Any change to that behavior is so fundamental, it simply doesn't happen.
> adopting vim vs. a top grade IDE
That is not what I, or most others are asking. Most people who use vim enter the "vim cult" simply because they enjoy using the tool. Even after decades of stagnation, they prefer vim to an IDE.
If there is something the "vim cult" wants, it is for you to let them use the tool they enjoy. IDEs inherently push tools out of their tightly defined (integrated) ecosystem. If someone wants to use the tool they like, and an IDE, they have to integrate the two. More often than not, that means a minimal implementation of vi inside the IDE.
TL;DR If I am in the "vim cult", you are in the IDE cult. All I want from you is to let people use their tools.
Why can I not have both?
> IDE
Integrated Development Environment.
Why would you want your compiler and your debugger to implement your editor?
That's like selling a hammer with every box of nails. Sure, I will be using both, but I really like my hammer. The handle feels right in my hand. The balance is just right. Your hammer is cheap and clunky. It may not bother you, but that is no reason for me to use it.
Vim is quite good at that too, you can set the make program and error format to execute the tests and easily navigate to the source of errors for example.
Certainly, though, you are using PyCharm vi emulation mode?
The interesting thing about your reply is that you focus on productivity/speed. And I think it's hard to argue (though I've seen people attempt to argue this) that time spent moving to/from keyboard is not so relevant considering software development is largely about thinking.
However for me vi-style text entry is not about productivity but about mental comfort. It turns your keyboard into more of a musical instrument and amplifies your ability to express what you want to happen on the screen. That's the case for me. That's why I asked about vi emulation mode, because that's what I think is the salient feature/innovation of vi(m).
* Ease of learning. Any power user learning Vim now (or in the last 20+ years) is coming to it with a headful of useful, versatile conventions and shortcuts that completely don't work. God knows how many times I interrupted my flow by reflexively hitting Ctrl-Z to undo, or Ctrl-V to paste, or Shift-Arrow to highlight, or, hell, just trying to type something normally. It doesn't even sync with other command line conventions. That "Type :quit<enter> to exit Vim" message appears when you hit Ctrl-C: Vim knows what you're trying to do, but it won't do it unless you ask nicely. As far as I can tell, there's no substantial advantage to Vim's mappings except that people who already know Vim can keep using them.
Which ties into:
* Discoverability. This is less about Vim in particular and more about command-line apps in general, but still. In a GUI app, if you want to do something but don't know how, you can often find it quickly by clicking around menus, and in the process you may find something else useful that you didn't know about. On the command line, you pretty much have to tab out and search for help, whether in Google or the man pages. (And of course learning to navigate command-line help is a whole different skill in itself.
On the other hand, I agree that starting out with CLI is a bit painful. IMO, the middle ground taken by Spacemacs really should be researched (and used) mode.
For a great number of tasks, being a vim or emacs pro means doing things faster than any other editor could do them (except, maybe refactoring). And vim will save you from from more RSI than emacs by having fewer modifier key combinations.
Every IDE needs a vi mode.
Wherever I can I use tmux+cscope+ctags+vim+shell as my IDE. One tmux session per-project, nested in one big tmux session for all projects. Window #0 has a cscope with a an $EDITOR wrapper that opens new edits in new, appropriately titled tmux windows and returns control to cscope. Windows #1 through #4 are for a shell. The rest are for editing files opened via cscope. It's a dream for C/C++, even Java. cscope needs support for more languages, that's true, certainly, but this gets me quite far.
So Vim is an addition where as my key bindings work everywhere except when I go to the console where I had to learn some nano specific key bindings but which match a lot with the basic text editing keybindings from Emacs mentioned above.
And if you use a laptop as a primary work tool, being able to avoid the touchpad (or trackpoint for those ThinkPad users out there) is a huge advantage.
Yes, yes, when I don't have my keyboard, I still use the normal vim features, but I try to use the keyboard as much as possible for anti-RSI purposes anyway, so its not a big deal.
edit: I've been getting slightl better at it by forcing myself to use VimFx on Firefox and cVim on Chrome and now I am planning to get IdeaVim for WebStorm and Android Studio.
She married a doctor just after college. So that's there. But I learned my lesson. No more "best of .." unless it's critical or is for vanity.
oh wait, they have tinder
ed is the standard text editor
Let's look at a typical novice's session with the mighty ed:
golem> ed
?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
---
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.
Memorize vi keystrokes is knowing the secret handshakes.
Able to Exit vim is finding the door to enlightenment.
If vi comes with an easy "back" button like all browsers, no-one will learn it. One needs to be trapped inside for a while to feel the power of the dark side.
It breaks about every convention on editors and discoverability that you're used to.
Start GNU nano. It puts me in a position where typing edits the file I opened. It shows me the name of the program. It shows some keyboard shortcuts for interacting with the program. (Though for beginners the ^X syntax isn't obvious either).
Vim, doesn't give me any of that. I infrequently use vim and I still tend to open a file and start typing without hitting i first, because it's behaviour that's inconsistent with every single other editor I have ever used.
Fun times.
Awk and python don't deal with stdin/stdout quite as nice (AFAIK) and there is always the temptation to do too much with them.
As an example, the other day I wrote a DSL in awk, it takes a mostly CSV file in and outputs sql commands. If you did it in python you could run the sql directly, but the awk stdio version makes it easier to combine as needed. If I want to run the generated sql I can pipe that to the sql cli client, if I need to hand it to QA I can just pipe to a file etc.
Isn't it posix mandated?
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/aw...
Then I came across "Actually using ed"[1], which did such a great job at explaining how to use the tool that I decided to throw in my 2 cents by submitting an entry to the tldr-pages project[2]. The rendered page looks can be found on [3]. Any feedback welcome!
1. https://sanctum.geek.nz/arabesque/actually-using-ed/
2. https://github.com/tldr-pages/tldr/pull/944
3. https://github.com/tldr-pages/tldr/blob/master/pages/common/...
http://lists.gnu.org/archive/html/bug-ed/2017-01/msg00002.ht...
The console's that the front-desk or clerical users used every day had a steep learning curve. It was something that you would definitely not be able to walk up to and just intuit.
However, once you figured it out, there is never going to be a faster UI that you are ever going to experience in your life until we figure out direct BCI stuff.
It was funny watching the new people come on board and insist that we should change the UI to something with a mouse (probably web based). They had no idea that more immediately intuitive was actually a step backwards.
My point is that just because something has a steep learning curve, that doesn't necessarily mean that it's a bad design.
However, the company has been building new web-based solutions for a while, but all of them have so called "cryptic mode" where you can still directly input the commands, as it is order of magnitude faster, mandatory feature for experienced old-timer travel agents.
And all the three big GDS need to be thrown into a fire. "Oh you want to add a person to the PNR? Well tough luck! Not a use case we handle!"
In Sabre emails can be like 70 characters long. But periods count as two characters, as do underscores, and @ counts as four. I mean given the choice between period and cross of lorraine I know which I am choosing to include.
https://sds.sabre.com/XTRANET_Access/sabre.htm
The @ is 0x2E20 in sabre hex
Note that's a characteristic of bad design, not a characteristic of CLIs, where constraining the UI to GUI, will merely result in a hard to use GUI, instead of a hard to use CLI.
Note that in an email or printed page I can provide any CLI walkthru and anyone can follow with minimal training ("Which key is the any key?"), but some purely graphical GUIs are impossible to discuss verbally, especially if badly designed (see above, and realize the badly designed ones are going to need the most help).
First, click on the icon that looks like a Rhinotia hemistictus nose, except its green. No, not that, thats more of a myrtle color, you want the really bright green one. OK, now if you see a screen that looks like a Type II Seyfert galaxy then you've clicked thru too far and need to click back. Oh no, there's no left arrow icon to go back, we outsourced development to save money and in the programmer's culture a left arrow is an obscene gesture indicating you mate with your sibling, so our discount software uses a thoracic vertebrae, superior side up, for its back icon, isn't that hilarious a "back bone" to go back oh those UX guys crack me up every time. Something thats one line at a shell interface that could have been cut and pasted in, can involve an hour of talking back and forth about a bad GUI.
> Note that's a characteristic of bad design, not a characteristic of CLIs
That's a characteristic of hundreds of developers creating features over dozens of years, and those features interacting with each other in subtle ways.
In my experience, even in small projects and codebases things get notoriously inconsistent very fast. It's a hard thing to keep, as it requires conscious effort and most developers don't care that much. And once something goes to production (or far enough in non-regression phase), it's a game over.
On top of that, AFAIU, in legacy systems, storage space was severely limited. Hence PNRs had a rigid structure that was not very extensible. That's another fact due to which implementing new features in a backward-compatible way might have been cumbersome.
It was so popular, you can still bring up 1-2-3 text menu equivalents in Excel by typing "/".
It does if the app is aimed at companies with high turnover where said learning curve poses a continual problem for users.
After 30 days of employment the first has spent 28 days at 90% efficiency, the other has had 7 days at 60% efficiency, 7, days at 80% efficiency etc.
A gradual learning curve could be much worse for companies with a high turn over.
The only thing I remember being really annoyed with was that there was no way (or no way I managed to find) to select all the text in a line in one go. The same was true for the editor (EZY). I kept pressing Ctrl + V to do a block-select and pasted all sorts of gibberish all over the place. Apparently, there are no line endings in text fields so it's not possible to get something like block-selection working.
But that was about the only thing that sucked from my point of view and I grew up with GUIs and touch-interfaces, like everyone else in my generation.
Discoverability is another problem. You can have weird keyboard commands, but make it possible to find them without searching stack overflow. I miss when applications had a big bar at the top of all the commands you could do and their keyboard shortcuts. I'm on chrome right now, and copy and paste is hidden away in a menu. And the keyboard shortcut for it isn't mentioned. How do you think people learned the keyboard shortcut in the first place? Or apple phones have a bunch of gestures that are useful, but no one knows about because you can't discover them.
"Control-C sends SIGINT" has been a standard for longer than "Control-C means copy".
I blame Microsoft.
(I still have a few Windows apps we use at work that use these standards; good to know they actually were a standard.)
How do you quit man? How do you quit less?
'q' to quit is pretty standard in the TUI world.
The <esc> at the beginning is only necessary if you've already got into insert mode. That said, it'll not do any harm.
As for if you stuck in insert mode, this is more akin to when you have text highlighted in a GUI editor, the shortcuts change because you're in a different mode.
Remember all editors have modes, vim is just a bit more in your face with them.
Copy and paste are also in the right-click menu, and the keyboard shortcuts are shown there.
> (Or should my games have used hjkl)?
I still play a game that does...
The terminal looks like this now: https://www2.le.ac.uk/departments/economics/images/bloomberg...
You can still do everything with the same keyboard shortcuts that have worked for 30+ years (pretty much everything with a number in front of it), and the layout of the screens generally don't change. But now everything on the mostly text-based view is clickable as well--everywhere you see a number you can click with a mouse.
Additional shortcuts are hidden behind menus, like "Settings" in the photo. But if you know the shortcut, no need to look at "Settings" first (which itself can be opened by typing 97 or clicking it).
You can get the top viewed questions here: http://data.stackexchange.com/stackoverflow/query/53109/ques...
git undo 1
Is there a valid reason to do this in the first place?
> git push origin -f
No standard way to undo that. Only do it if you must, and you absolutely do what's going to happen. Always do a "got remote update" immediately before the force-push and double-check that the remote branch points to what you expect.
As a general rule, "--force" is short for "you better be prepared to deal with the consequences".
Remote reflog contains this info (if enabled).
Of course not all commands would be reversible, especially not plumbing.
EDIT: the replies to this don't get how feature requests work. yes, I could write this basic feature myself. thanks.
A minor usability investment on the part of 1-2 git developers would prevent thousands of hours wasted by newbies and perpetual intermediates (https://blog.codinghorror.com/defending-perpetual-intermedia...).
#! /bin/bash
git reset HEAD~1 && git checkout . [alias]
undo = reset HEAD~1 --mixedhttps://stackoverflow.com/questions/2003505/how-do-i-delete-...
Pretty sure I've got the command down by now, but it's embarassing how many times I forgot the exact syntax. It was especially bad before the "--delete" syntax was introduced.
Though at least now github provides easily access buttons.
I suggested a long time ago that vi/vim bind ^C to exit. It currently is equivalent to 'esc' (it puts you into command mode if you aren't there and types the message "type :quit<Enter> to exit Vim". I'd much rather it popped up 'exit vim? y/n?' and the next key would determine if you exited or not.
if people don't notice the "Type :quit<Enter> to exit Vim" message, they also won't see the (Y/N) selection.
so, absolutely nothing gained by making this change, except making things more annoying for people who do know how to use vim.
> E37: No write since last change (add ! to override)
It is prompting you to add a !
https://stackoverflow.com/questions/1019573/save-icon-still-...
Then I finally took a little bit of time to learn vim.
I was in a hurry to learn Linux and knowing vim was you know required. So I just learned the most basic in vim. I don't want to think about how much time of my life I wasted because I didn't know more about vim. Classic lesson about technical debt costing time/money over long term...
chmod 0644
[Esc] :wq
Sincerely, that other guy on your multi-user OS.
Ditto `:wq`. If you're in vim, and you don't know how to exit, you probably don't want the random keypresses you made while trying to figure out how to exit to be written to the file. Another case where an alternate version might be better: [ESC]:q! nano <file>
# apt-get a_life
I am a vim user, but I want to switch to something different. I mainly use it now, because of inertia. Don't bother with replying how editing model of vim is still relevant today. Or how one should think about vim as a language - a verb and a motion. I know all those arguments and I even agree with them to some extent. However I would argue that vim's interface is quite taxing for the mind - at least for my mind. Editing may be efficient, but I read more code then I edit.
I once helped organize talks at my school, and helped with bringing Richard Stallman to give a talk one time. I was a vim user, but I did a little bit of prep and refreshed my emacs memory etc. So we're setting up the room for the talk, and we're talking a bit, and some people start to arrive. He asks one if they've ever used emacs, she says no, so I said, "we should start an emacs tutorial here, we can teach everyone about things like C-x C-c, and stuff". I just blurted out the only thing I had remembered recently. He turned a cold shoulder to me, I suppose thinking that I had insulted him directly. I ran out to Google what I had said, and then felt terrible about it, but it was too late. That's my remembering how to quit emacs story.
B. Kernighan: have you ever used Unix?
Student: No.
You: Hey, how about we start a Unix tutorial here; we can learn all about dollar-sign-1, and stuff.
B. Kernighan: * roll eyes *
:)
C-M-handstand-q-footpedal
It would be terrific, particularly for Lisp development with SLIME.
MIDI foot controller -> USB MIDI interface -> computer -> driver -> user space scriptology ...
What do you think? That would easily give you ten pedals.
I use a 1993 vintage ART Ultrafoot X-15 I got off Craigslist --- for my guitar rig, not a text editor. :)
Perhaps, exit-emacs or quit-emacs aliases could be defined.
Overall, both are about as hard to deal with. Vim has a better help message, but it's still difficult to find.
Pretty straightforward.
> Pretty straightforward
If this is a joke, it's totally whooshing over my head right now
Straightforward.
But I just had to explain my own joke, so I'll go wallow in shame for the rest of the day. :(
It's too easy to hit accidentally, though. I got burned by it a few times, so I eventually unbound the command. I now use M-x kill-emacs when I want to quit (very rarely, anyway).
;)
I told the trying to exit vi joke for years until someone pointed out to me that C-x C-c was equally if not more obscure. It was a part of me because that was the first thing I ever learned about Emacs. Just like :wq was the first thing I ever learned about vi.
Now, I think the fact that people seem to have more difficulty exiting vi is because vi is very likely the fallback for $VISUAL/$EDITOR, and hence much more likely to be trapped in by accident when unprepared.
[1] https://twitter.com/iamdevloper/status/435555976687923200?la...
Because your keyboard is stuck on permanent caps lock and you cannot remember the alternative to ':wq' which you cannot enter due to the perma-caps input device that requires a reboot to become a keyboard again.
If you use Synergy then this happens and a reboot can be easier if you are stuck.
In theory you really could forget 'ZZ', I nearly forgot '=aB' for some reason recently, this '=aB' to indent is only really known in muscle memory and the actual '=aB' text is entered and gone quickly from the bottom of the screen, so never seen, merely memorised as muscle memory, not a written or vebalised thing.
I attribute the weirdness of Vim to it being like learning a completely different actual language similar to learning French if you're an English speaker.
With an editor you do almost everything through muscle memory, and so like speaking a language it's subconscious.
Unless you've got a French English dictionary or Google Translate you've got very little hope.
The problem is most GUI editor users assume that it's just an editor like they're used too.
The only way to learn it, is like a language by speaking it all the time and changing the pathways in your brain.
I want to get round to writing a translators guide for Sublime Text users on the basis that's probably the most similar GUI based editor to Vim. Then most people can translate their own editor to what ST does and from there figure out Vim.
I'd say no. I work in Japan and here everybody uses a Japanese equivalent of StackOverflow. This conclusion is so wrong.
From my experience, people at least from Korea are very likely to develop on windows, even when targeting linux or even embedded linux.
You can tell from the msdos line endings and comments in Korean that are in a weird multi byte encoding that I could not make vim display correctly. I think they use some sort of sftp synchronization tool like WinSCP when you edit a file remotely.
I read that Windows is really deeply rooted in their IT culture, so much so that banking sites are required to use a special encryption scheme implemented in ActiveX. I can see why that would discourage people to use a different OS for their daily needs, let alone convince corporate IT to support dual boot.
<crtl>+z
kill -9 %1(vim captures ^Z in input mode)
More likely it means they are running Windows...
E492: Not an editor command: Wq EDITOR=/Applications/TextEdit.app/Contents/MacOS/TextEdit
cd /usr/bin
rm vim vimtutor
ln -s /Applications/TextEdit.app/Contents/MacOS/TextEdit vimThey end up using Emacs lisp to create all other operations that they ever need on the computer. Emacs becomes their only environment.
Whenever I write code (or anything else) in another editor I still always have to carefully check diffs to confirm I don't have any vi control mode characters interspersed with whatever I was writing.
But I still can't quit using vi for everything else or my productivity goes into the toilet.
vi why can't I quit you?
> Hold on a minute! This is a WWW page in English, and yet you have the Ukraine, Turkey, Indonesia, and Pakistan as the top four countries by visitor? And the highest placed majority anglophone country is Canada, in sixteenth place? Hold your horses! Something is not right, here.
I have seen this pattern myself, on one of my WWW servers. Ukraine and the Russian Federation are second and third on the list ... for HTTP. For HTTPS. however, it is a very different story.
On the basis of my own experience, I question the accuracy of the statistics posted, and the accuracy of the conclusions based upon those statistics.
I once typed "EDIT" to Interlisp when in the wrong mode, and Warren Teitelman's "Do What I mean" system printed "=EXIT" and exited the program without saving. DWIM was tuned rather closely to Warren's personal typing errors.
ZQ - Quit without saving
ZZ - Quit with saving
In my experience almost all of my colleagues over the past 5 years only new of :q, not ZQ.
[1] Would have been emacs 18.something at the time. Not sure if that predates the built-in tutorial or if I just missed it. I remember running the tutorial not long thereafter on a proper workstation where I felt comfortable I could close the window.
Anecdotally, would get stuck in Vim having thought that the override command was :!q instead of :q!...
Interestingly, I found domains like howtoexitvim were registered immediately after this post showed up on HN.
Perhaps the mission is not complete and you should keep the file open until there are zero defects, everything is properly commented and you 100% understand everything and then some.
At that point _maybe_ Vim shall let you exit!
:)
Good times.
> Github search for ":wq" returns more than 7,000,000 results https://github.com/search?q=%22%3Awq%22&ref=cmdform&type=Cod...
https://twitter.com/kennethn/status/470771879397949441?lang=...
Isn't it just...
[Esc] :wq
...or...
[Esc] :q!
...depending if you want to save the current document or not?
[EDIT] also, a typical mid-level computer user's tendency to slap "ESC" when panicked. Ha!
If there is such a thing as user hostile in the world of CLI tools, then dropping the user unannounced into vi with some open buffer most definitely counts as user hostile.
git rebase -i
For example
Then, the program tells them "Type :quit<Enter> to exit Vim"
And if the user is capable of reading, they shouldn't have any problem.
If they don't know about ctrl-c, they shouldn't be using a terminal editor.
But if you've typed anything, this won't quite work. <ctrl> c will take you out of insert mode, but won't offer any prompt. <ctrl> c again will bring up the quit prompt, but that's not intuitive the way doing it the first time is. And if you type the wrong thing after the first <ctrl> c, you'll break back into insert mode and have to take another run at it.
I remember getting stuck in vim because git bash uses it as a default editor. It happened when I forgot to enter a commit message, which meant that I started typing a commit message and thereby lost the useful prompt when I went to quit.
edit: per another thread, this gets far worse if you don't realize the ':' is active and not a prompt to "type: quit". That error sets off a maze that will never show you the prompt again to find your mistake.
If you try to <ctrl>-c, the program even tells you to use :q
It's just become a meme at this point.
Edit: ah quit foreground process, ignore me
<ctrl>-c is how you kill the foreground process in bash, zsh, sh, windows command line, etc...
If you don't know about <ctrl>-c you shouldn't be attempting to use a terminal based editor to begin with. Vim can't be blamed for people not knowing how to use a terminal.
And then you do and it helpfully adds ":q" to the buffer.
You're still in vim.
I don't blame people for being confused though.. I remember getting stuck in vim all the time back in the day because of a default $EDITOR value.
I love vim and I've used all of those at some point. I'd never pretend there's no learning curve, just that the learning curve is worth it.
[Esc] :x
to save and exit.
"I've been using vim for 10 years. I never could figure out how to quit."
You won't get out of notepad that easily.
1. close terminal
2. remove all the temporary .swp files from the open buffers i just aborted
!killall -9 vim
So the first screen doesn't help in this situation
The sort of developers who get stuck in Vim are not the ones who are using it intentionally
>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
while True:
print(str(eval(input())))
>>> x = str(quit)
>>> x
'Use quit() or Ctrl-Z plus Return to exit'
It does, it just does not care.
> it's basically just a hack around the fact that the repl is basically:
I know what a REPL is. Here's an idea: it's not difficult to add an exit special case to the REPL.
> Case in point:
Case in point: the developers added a "help text" to tell users to go fuck themselves, knowing exactly what users wanted to do and refusing to do it. quit's repr didn't appear by magic, it was put there, knowingly, by people who understood exactly what they were doing.
I don't program Python much but do its users constantly type "quit" but not actually want to quit such that the REPL special cases this situation?
That one would probably be somewhat risky actually, that message is the "repr" of the quit object/function, displaying results at the repl invokes repr… but so does printing most containers, so e.g. `vars(__builtins__)` (to get a quick list of the builtins) would also quit the repl, which would be undesirable.
The repl treats it specially because "quit", taken out of the context of the repl, makes sense as something to type in when trying to quit an unfamiliar program, not because actual Python programmers are likely to type it often.
They're different programs with different UI conventions. I don't expect them to act the same. And I especially don't expect vim to change, after having 25 years of its own precedent and an additional 16 through vi.
In both cases, this is because there's a race condition:
If you run a command and decide you want to kill it, you use ctrl-c. If the command finishes between you deciding to kill the command and the signal being sent, the "container" process (vim or python) receives the ctrl-c. If it always assumes "what you want" is to exit, you've maybe lost work - edits made or variables populated. Avoiding that is definitely the right call!
I think in this case vi's authors (and by extension vim's author) have picked the right choice of catering to the actual users, rather than being friendly to people who run the editor by mistake. At least they try to tell you "type :quit and press enter to exit".
Muscle memory can be a real pain some times.
Had switched from Ubuntu to Fedora and it turns out that vim was the default git editor not nano (until I switched it anyway).
me: Hit escape first, then :q
dev: Oh, then why doesn't say escape then :q
me: welp
It happens because people don't what they are doing. You assume that they hit ctrl+c, then immediately type :quit, but if they did, then they wouldn't be Googling it. They did something between trying to exit and quit that got them into a different mode.
What I'm saying is the screen that says
VIM - Vi IMproved
version 8.0.567
by Bram Moolenaar et al.
Vim is open source and freely distributable
Sponsor Vim development!
type :help sponsor<Enter> for information
type :q<Enter> to exit
type :help<Enter> or <F1> for on-line help
type :help macvim<Enter> for MacVim help
"Type: quit<enter> to exit Vim"
Since the colon is used a separator such as I used it above.
Then they type "quit" and enter, which actually put them in insert mode recording "@u", with a 't' sitting in the text area.
- You enter an unfamiliar mode, immediately hit "^c".
- That prompts "Type :quit<enter> to exit Vim".
- You mistakenly type "quit<enter>". So now you're in insert mode with recording, as you said.
- You hit "^c" again, breaking out of insert mode, but you don't get the exit prompt like you did last time - the `recording` message blocks that no matter how much you hit "^c".
- Without the reference message to find your mistake, you maybe try "quit<enter>" again. 'q' now terminates recording, 'u' undoes your typing, and 'i' dumps you back into insert mode, leaving you with a text field of 't' again!
- At this point you maybe hit "^c" again. That'll drop you out of insert, but with text in the field vim no longer prompts you to quit. If you enter "^c" again it will prompt you, but you tried that during recording mode and it did nothing, so you don't expect aimless repetition to help anything!
At this point, you give up, google "quit vim" and discover that the colon was important. I'm pretty sure this madness if what I did the first time git for windows popped open vim as the default editor.
The only way the above would work as suggested is if the person hit an insert mode key first after having typed Ctrl+C.
On the other hand that only happens if you type "quit" without the colon and the message makes it very clear that the colon is part of the text you must enter:
Type :quit<Enter> to exit Vim
So you can get stuck in a dubm situation but it's not terribly easy.
Except, logically, why would they bother to specially call out <Enter>, a whitespace character, but not the spaces as well if they intended the user to type them?
I can't think of any obvious, safe way to display text that a user should type that isn't subject to possible misinterpretation in the single line of output available.
If nano were the editor you end up in, you would have the same problem.
Not everything has to be easy to use, some things benefit from not being obvious.
That said, as others have pointed out, the vim developers can't really be blamed here as it's just a very hard problem. There isn't a common convention, and vim already goes above and beyond to try and educate users on how to get out. People ending up on this SO question just seem unwilling to read.
Sounds like a distro problem.
macOS is another potential culprit - can't remember the default there.
The problem vim has is that its UI is entirely organized around modes, which makes the "people are terrible at using modal interfaces" problem a hard one for it to cope with.
You may as well expect Porsche to move the 911's engine to the front.
The vast majority of people don't use vim, so this "solution" has already been widely adopted. (Which in turn causes people who like vim to periodically wonder why more people don't use it.)
The problem comes because there are scenarios where you don't have a choice as to which editor to use; if you're shelling into a server with limited privileges, for instance, vi/vim may be the only even remotely modern editor available. So lots of people find themselves forced to use it, and these are the people for whom the Stack Overflow thread is useful.
Like... nano? Or pico? All quite broadly available, and easy as dirt to use. You can even use them to work with `visudo`, one of the few times where I could imagine you don't have a choice.
Also, if you can edit it remotely over SSH, you can scp it in two directions and use your own favorite editor (assuming that editor doesn't already have something like network editing already built in; most do).
If you "don't have a choice", you're not looking hard enough.
That said, any server admin who for whatever reason allows people to SSH in (shared hosting maybe, university, file sharing) should have nano installed. Anything else is just cruel!:wq
They probably learned how to do that in a Stack Overflow thread as well. No competence necessary.
Do we need to spoon-feed you people the solution for all of your problems?
Use SSHFS to mount your remote file system, and edit your remote files with your fancy, LOCAL, non-vim editor.
That doesn't sound like a reason to change vim, it sounds like a reason to change the configuration of the server to something saner. pico/nano makes sense to me, if the expected users are the kinds that wouldn't know how to exit vim or emacs.
People "terrible at using modal interfaces" should just use another editor.
The problem might lie in other applications indirectly launching VIM, taking for granted the users' familiarity with it.
Not to mention your OS is full of modal interfaces. "Why can't I type?" "You have a menu open." "Why can't I type when my cursor is over this window?" "You have a different window as your focus." "Why doesn't space pause this YouTube video?" "Because play wasn't the last button clicked." "WHY ALL CAPS?" "Check your capslock key."
None of these are examples of modes, at least not as the term is used in the context of user interfaces. (See https://en.wikipedia.org/wiki/Mode_(computer_interface)#Defi... for more information.) Modes hijack the entire behavior of the application until the user switches out of them. Windows and menus aren't modal unless they block all other input until the user deals with them.
On the other hand your last example, the CAPS LOCK key, actually is modal; once it's engaged, everything you input is going to be capitalized until you disengage it. You will also notice that the CAPS LOCK key is a common source of user problems in tasks where capitalization is significant, like entering passwords; and that for this reason there are frequent calls to remove it from the standard keyboard layout.
Ditto the multi window scenario. You have to actively change focus between windows (often between windows in the same application), until which time the application doesn't respond as you expect it to.
Another great example: spreadsheets. You're in one of two modes, editing a cell or moving around cells. Often without great feedback of which mode you're in.
Modal interfaces are everywhere.
They're often not intuitive, but intuitiveness is not the be-all and end-all of interfaces. It's a trade-off.
The problem is you do crontab -e or something similar on a new or foreign system and get into vim and are now stuck.
Which would be?
Doesn't work there, either. Most of those don't even offer advice on how to exit when you hit that combo, do they?
So, how is Ctrl-C the right answer then?
Use nano if that's what you want. There's no reason to fuck up vim for people who actually use it to help the people who don't.
The impact on vim users would be virtually nil whilst also respecting that non-vim users are caused problems. Who is most to blame is not usually the most helpful focus.
> that no actual user of the software has? It's not an iphone, it isn't meant for use by the general public.
You're obviously wrong.
Millions of users of the software have that problem. It is used by the general public. It's irrelevant whether they intended to be users of the software or not. No one decides on a distro based on the default text editor, and some people are still learning how to use nix and won't know to change it right away.
Plus, from vim.org:
> It's not just for programmers, though. Vim is perfect for all kinds of text editing, from composing email to editing configuration files.*
Sounds like vim is for use by the general public to me. It just isn't very good at usability.
>Many of us get dropped into vim by accident.
>> It's not just for programmers, though. Vim is perfect for all kinds of text editing, from composing email to editing configuration files.*
can be used for anything != should be used by everybody
>It is used by the general public.
Laughable.
You could say "I'm somewhat amazed but mostly amused that the Git developers care so little about user experience that they continue to ignore that people have trouble with the fact that git command line arguments are an incomprehensible morass of inconsistencies un-righted by overly verbose walls of documentation."
What the two have in common, of course, is that despite being exceptionally beginner-hostile, the tools are massively popular for other reasons. Namely, they are powerful, relatively fast, and they also strongly benefit from cult of personality and network effects.
Want to quit vim? How's about:
1- Hit ctrl-z
2- Type "kill -9 %"
3- Hit enter
Result: dead vim. Heck, dead anything that was previously on the foreground.
This works with emacs, vi, nano, and, I guess pretty much everything, since ctrl-z is captured by the shell and never gets sent to the application (I think).
Nor how to open a separate tab session, do a `ps`, and kill that.
It should be shell 101, but it's not.
[0] autocorrect lol of the day: "I'm a vi[rgin]"
The default editor in distros could be set to nano or some other reasonably 'windowsy' editor instead. Those who want vi or emacs know how to fix it anyway...
Vim's defining feature is the keybinding grammar, so it would no longer be Vim if you changed it.
Modal editing is fantastic: it means you don't need a meta key, or multiple modifier key combinations to do things (for which your wrists will thank you!). It frees up keybindings for different purposes, which is partly how modal editing ends up needing fewer modifier key combinations.
Best thing in editing technology yet.
so forget about all the people who have used vi for decades?
It might make sense to have a bar at the bottom or top with some of the very very basic commands a new user may need (like quitting) that more experienced users can turn off with a command line option or a config value. (specifically if say you do crontab -e or something similar and had no intention of using vim and are now stuck)
It's not like other editors behave much differently than vim. Try for example to get out of an "git log" with CTRL-C. Or figure out what the key combo ^x in nano means as a novice.
VIM is a bad default editor for that reason. But don't blame VIM for being what it is. Rather convince your distro or whatever to set nano as the default, easy to learn, editor.
[1] http://wayback.archive-it.org/all/20150203071645/http://cm.b...
There's kind of a trend of tools that are bright and shiny, but not actually that good at their main purpose. You hit a plateau. We don't need more of these, we need more tools that are bold enough to be powerful, even if they're at first hard to learn.
____________
[1] As in command and edit modes.
We detached this comment from https://news.ycombinator.com/item?id=14405790 and marked it off-topic.
Middle
Aged
Computer
Scientists.
E.M.A.C.S.
Besides, won't every currently young computer scientist be a middle aged computer scientist soon enough?