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 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.
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.
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.
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.
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.
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.
* 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.
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.
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).
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).
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?
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.
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 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)
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:
eat flaming death
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.
Then I came across "Actually using ed", 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. The rendered page looks can be found on . Any feedback welcome!
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.
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?
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.
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.
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.
The @ is 0x2E20 in sabre hex
It was so popular, you can still bring up 1-2-3 text menu equivalents in Excel by typing "/".
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.)
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...
How do you quit man? How do you quit less?
'q' to quit is pretty standard in the TUI world.
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.
The <esc> at the beginning is only necessary if you've already got into insert mode. That said, it'll not do any harm.
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.
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 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...
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.
git undo 1
undo = reset HEAD~1 --mixed
Remote reflog contains this info (if enabled).
Of course not all commands would be reversible, especially not plumbing.
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".
EDIT: the replies to this don't get how feature requests work. yes, I could write this basic feature myself. thanks.
git reset HEAD~1 && git checkout .
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...).
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 !
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...
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?
You: Hey, how about we start a Unix tutorial here; we can learn all about dollar-sign-1, and stuff.
B. Kernighan: * roll eyes *
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.
Overall, both are about as hard to deal with. Vim has a better help message, but it's still difficult to find.
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. :)
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).
Perhaps, exit-emacs or quit-emacs aliases could be defined.
> Pretty straightforward
If this is a joke, it's totally whooshing over my head right now
But I just had to explain my own joke, so I'll go wallow in shame for the rest of the day. :(
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.
kill -9 %1
(vim captures ^Z in input mode)
More likely it means they are running Windows...
E492: Not an editor command: Wq
Interestingly, I found domains like howtoexitvim were registered immediately after this post showed up on HN.
rm vim vimtutor
ln -s /Applications/TextEdit.app/Contents/MacOS/TextEdit vim
They 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.