I met my wife because she was stuck in VI. I was a unix sysadmin in the early 90s, and she was a grad student. She came to me for help (like most of the 1st years did) because she couldn't get out of vi. However, to be fair, this was not her fault per-say. She actually knew how to use vi, but just couldn't find the ESC key.
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.
I love both of the above stories. Mine is not quite as good. My wife was assigned to test my code (Microsoft's CodeView debugger ported to other processors), and one of the reasons she married me was that it didn't introduce new bugs.
Most people have no idea why vi made sense way back when (and, in my opinion, does not today).
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.
It is the only editing system that makes sense to me. That's because modal editing means fewer modifier-key combinations are needed, and no mouse is needed. Compare with.. any other editor, where the only thing that might save you from RSI is enabling sticky keys, and even then, if it isn't emacs you still have to heavily use a mouse.
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.
To me, using "no mouse is needed" as a positive is like building a car that uses extra pedals to steer and saying "no steering wheel is needed". Mice are great. I want to use mice.
Mice have their place. But they have issues with precision, RSI, and force the need to move the hands to/from home row.
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.
http://www.edkeyes.org/blog/050728.html
Somewhat ironically, the inventor of the computer mouse, Douglas Engelbart, is still a bit critical of modern graphical user interfaces compared to the fuller vocabulary of, say, the command line. "Here's the language they're proposing: You point to something and grunt," he says.
I love vim, but I do feel that my reliance on its awesomeness has been reduced quite a bit since I switched to using a Kinesis Advantage keyboard. For one, the cursor keys don't require me to move my hands at all, so I no longer use hjkl to navigate. I also have quick easy access to all modifier keys and I use a foot pedal too. I do still use vim, but I've essentially mapped all of the fancier features to pedal+main keybaord single button shortcuts - Kinesis Advantage macros also means it works fine in a stock vim.
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.
Yes, you can use a lot of other editors without a mouse. The advantage of learning vim/vim mode is that you can be proficient with them without having to learn their editing keybindings. Vim mode acts as a common interface. I even use those keybindings in Chrome with cVim.
This is also not exclusive to Vim. I don't use any plugins and I have a lot of common key bindings (especially for text editing) I can use on every text editor field on my Mac (which are pretty similar on Windows). Heck I even have Emacs keybindings on OS level on macOS nearly everywhere (without installing plugins): http://jblevins.org/log/kbd
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.
I don't know Vi(m) well at all and that's mostly my impatience and procrastination. Just like I could never truly touch-type. But I totally get how Vim is excellent at what it does and hence why it's important. Not using the mouse and not having a lot of distraction are godsend when doing any work worth your time involving lots of text whether it's reading, or writing code, or a story. Also, I've kind of never even seen all those ancient gadgets you have named - I feel this based on my exp with computers (and starting with a Dell Vostro) since 2007.
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.
Spacemacs solves the problem of discoverability by displaying all modal keybindings currently available, if you started typing a modal command sequence, but haven't completed a command yet. The additional bonus here is that once you internalise these commands, they stay the same while you execute them much faster. In mouse-centered environments, one would first learn how to do an action using a mouse and after he felt the need to be faster, he'd need to learn the key combo from scratch (for the sake of the argument, let's ignore the few common conventions like F1, cut/copy/paste and undo/redo).
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.
In all of the discussions on HN about vi/m this is probably the most intelligent question I've received after posting my opinion.
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.
Since you mentioned using a trackball due to carpal tunnel when using a mouse I thought I should share my setup. I don't really suffer from these issues (with the exception of scrolling) but it pays to prevent them.
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.
This is very interesting. Since the trackball worked well for me going back nearly twenty years I stopped looking for other solutions. I coded for 20 hours yesterday and I'm perfectly fine today.
> 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.
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.
If someone's train of thought is interrupted by the difference in code entry time between vim and a good IDE or code editor --which is milliseconds-- they have a real problem requiring medical attention.
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.
I get the impression that you haven't gotten proficient in an editor like Vim or Emacs. The difference in speed in terms of getting your thoughts out of your head into the computer is definitely more than milliseconds. I usually use Emacs, but I use an IDE for Java, because I think the benefits outweigh the costs, which is why I said I mostly agree with you. What I find frustrating is that there's no reason an IDE couldn't be as good as Vim or Emacs for editing text while retaining all of their IDE goodness.
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).
> A lot of the vim "religion" centers around keeping your hands on the keyboard, not using the mouse, carpal tunnel and speed.
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.
Editing text is maybe 9% of what I do. Most of my work consists of reading text, thinking about it, running tests, reading the results of those tests, thinking about what I've read, discussing what I've been thinking about with coworkers, reading more text, and thinking some more. It has been this way for most of my career. This is what I see most of my coworkers doing, too. Editing text more efficiently simply wouldn't make any measurable difference in my productivity, because editing text doesn't take up that much time to begin with.
Personally, I don't care about "efficiency". I care about usability. Having a tool designed to edit text let's me focus on everything else. Sure, there is a learning curve, but you don't need to be an expert to find the tool useful.
vi wasn't designed to efficiently edit text. It was designed to deal with shitty keyboards of the time. And now it is a cult.
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.
That is precisely my point. To devote any effort at all optimizing this is to go after the wrong optimization target. Just buy or use a good IDE that helps you with tasks beyond text entry and move on. There is no value to be gained doing anything else.
> Just buy or use a good IDE that helps you with tasks beyond text entry and move on.
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.
> Most of my work consists of reading text, thinking about it, running tests, reading the results of those tests
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.
I think you're right. Nowadays I only use Emacs+evil for Org-Mode and languages that don't have strong tooling yet.
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.
It's kind of funny watching people who've never used one try to adjust to it. My kids grew up with them and wouldn't use anything else. They have them on their laptops too. I hate laptop touch pads, the single worst UI ever put on computers.
Yeah, I mean, I try to explain the appeal, and nobody is even willing to give it a shot. I can't help but laugh when someone tells me how their Magic Trackpad thing is so much better. The precision is terrible, it doesn't improve on all the standard mouse type of constant wrist movements, and so on. Sometimes I joke that trackpads were meant for species that haven't evolved thumbs, or haven't learned how to use them. :)
She already knew vi. Probably better than I did, as she'd done her undergrad at MIT, and already knew unix.
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.
Hottest girl in my class had asked for help with how to install a free antivirus on her laptop because the 1 year free-with-laptop McAfee had expired and she was getting dengerously annoying prompts and thought her laptop might be hacked. By the time I was done with "best free antivirus for Windows" someone else in the lab had done it. In my defence I was a linux guy.
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.
I wooed my wife by being able to solve a computer problem as well. Her laptop wouldn't boot, and she had a paper on the hard drive that needed to be submitted that day. "I have just the thing," I said, and I ran home to get my drive-to-USB adapter. Pulled her hard drive, recovered the paper, and printed it from my own laptop. The rest is history.
(Attribution is questionable, but as a geezer I feel the need to make sure the younger generations at least are familiar with this:)
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.
(As a geezer, I also have to say I really am impressed with ed in some ways, and you should never be afraid to try it when you have a specific and known edit you want to do.)
After reading lots of similar anecdotes about Ed (Steven Levy's "Hackers" dedicates quite a few words to it), I was quite sure it was pretty much unusable for today's UI patterns, but also morbidly curious about how it might eventually work.
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!
"When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a “viitor”. Not a “emacsitor”. Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!"
Using vi/vim lets one enter a secret dark corner of programmer society.
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.
Yes it is, if you are coming from a GUI life, start using the shell for the first time, and suddenly get thrown into some unnamed editor by git. :P
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.
My worst memories of starting out with programming is doing a git merge or pull, then before the command was done, I'd start typing git push or... and then I got stuck in insert mode. This was after I had learned that :q och :wq! did the job, and I could not for the life of me figure out how to get out of insert mode.
Or because every other editor you've had is inconsistent with Vim. It is dumb if people are being dumped there by Git. I guess if you try to use it and get stuck it is a lot easier to escape than if someone gets dumped there without even knowing where they are.
I recently had to use ed. I wanted to write a handful lines of code, but for that I needed the context that was in the terminal history. I didn't want to keep switching back and for with vi. So I decided this was the time I should learn ed. It did the job it was expected to do, I was not disappointed.
Excellent point. I'm an Emacs guy by habit, but I'm also a sysadmin, which means I keep a well-stocked repertoire of ex commands ready for when the shit really hits the fan.
I find that with a specific and known edit, it's far easier to do using sed and awk. In particular awk Has better power-to-weight ratio at traditional text processing. I think typical awk scripts could very well be shorter than the equivalent python scripts that do the same thing.
I have written hundred+ line awk programs. For stream text editing it is excellent at what it does and it's install base is huge. Rarely do I encounter a *nix machine without it on there.
Perl & Python are also installed on most UNIX machines I've seen. I know Perl was invented to address weaknesses with Awk. I use all 3 to some degree, but is there a reason you like Awk?
The pattern -> action format of awk is really nice for simple apps, it's a built in for loop + switch statement that reads from stdin. It's also simple to change what the record/column seperators are, so it can handle some quite complex data shapes with zero code.
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.
Neat, will have to look into that. I think Perl might have a command line switch with similar behavior that runs your command across every line of whatever you pipe to it, but that might not be what you're saying.
yjftsjthsd-h, I'm curious so I looked it up but couldn't find anything. AFAIK POSIX only specifies operating system behavior and doesn't specify any actual apps but I could be wrong there. In any case, the rise of containerization has brought many nano Linux distributions that often have even fewer packages than even the most minimal distributions of years past.
I spent almost 10 years doing IT for a company whose backend was based entirely on as/400. If you've ever used a system like that, I'm sure you know where this is going...
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.
I work for a reservation systems company (a GDS) that is used by thousands of travel agencies. Of course, since the system was created 30 years ago, you were only able to create reservation with a text-based interface at the time, with short commands, inconsistent and complex flows to do some non-trivial things etc. So it's despised by newcomers because learning curve is steep.
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.
"inconsistent and complex flows to do some non-trivial things"
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.
> "inconsistent and complex flows to do some non-trivial things"
> 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.
You should see how Sabre handles email address with it's bizarre, limited, possibly 7bit character set from 1959.
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.
What character encoding do they use? ASCII is 7-bit, all those characters use 1 byte in ASCII, and of course email addresses were originally (and until recently?) restricted to ASCII.
There's certainly a trade-off between learning curve and long-term productivity. But the problem here is that vi/m gives shitty feedback, that's all. It should say "Press <ESC> and type :quit<Enter> to quit VIM" but it doesn't. Most first-time users lack a mental model of input modes, so they get stuck.
I think your are mixing steep learning curve with having keyboard shortcuts (whether they are commands or combinations of keys). You can have keyboard based shortcuts with any UI. Actually a UI with no shortcut is probably a bad design in the first place. A steep learning curve just means it is hard to learn, i.e. non intuitive, non discoverable. These are not qualities.
I just hate programs that change patterns that are standard everywhere else. E.g. 99% of software uses control+c and control+v to do copy and pasting, so of course software that maps it to something totally different is going to be very frustrating. The same thing with vim using nonstandard way of quitting.
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.
I'm well aware of that and the historical reasons that it's the case. I'm just using it as an example of breaking well established patterns that screw new users.
Don't worry, in few years new bindings will be familiar to new people straight from their birth date. Then they will complain about changes and you'll tell them that changes were made long before.
Shortly after the introduction of the first generation of brain-computer interfaces: "Why do I have to think of Ctrl-C to copy text in this program? All the other programs have me think of a banana to copy a selection!"
> 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?
Copy and paste are also in the right-click menu, and the keyboard shortcuts are shown there.
I hate VI not defaulting to wasd for movement like every other single piece of software I used growing up... (e.g. Quake, Marathon...) Ha ha ha. (Or should my games have used hjkl)?
Well it's not quite that simple because it's more complicated than those tools. Once you are in ex mode ':' though it uses the standard exit key.
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.
I worked on Z/OS mainframes for a couple of years and the point-and-shoot interface is indeed very efficient, once you've learned to use it.
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.
A bit late to the convo here, but one of the things that really impressed me about the Bloomberg (my employer) Terminal is how they manage this old user vs. new user problem well.
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).
If there is high turn over then the length of the learning curve is more important than the shape of it. Let's say there are two apps each with an employee starting, one requires two full days of training to be 90% proficient, the other allows for an instant start with a more gradual learning curve.
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.
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.
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".
I saw the bumper sticker ":w saves" and thought, to myself I wonder how many people "get" that.
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.
That looks more like emacs behavior though, vim rarely (never?) prompts the user for anything. You enter a command, you get a reaction (either an action like quits vim, or a message indicating something happened) -- which I personally prefer much more than getting annoying prompts.
It has closer things to prompts. Try editing a file when the last time around you terminated vim without giving it a chance to clean up its .*.swp file. (-:
Actually you get a prompt when you try to save a file that has been modified in a different session or when you switch to a similarly modified buffer. But those are pretty reasonable and don't happen that often.
I'd vote against that. I use ^C as the best "esc-replacement-without-straying-far-from-the-home-row" that works in every install, every emulator and every international keyboard.
Hah. Back in the old days, when I didn't have a second computer to look up help online, I just powered my Linux PC off if I accidentally got trapped in vim. Later on, I'd just close my PuTTy session.
Then I finally took a little bit of time to learn vim.
Haha. I survived using vim JUST knowing Esc and :ws for years~.
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...
When I told my thesis advisor (in about 2001) that I was looking into backend web development as a career, he gave me a post-it note with the following content:
Not sure if is there is something more subtle in the note but around 2001 (or even later until today) chmod -R 777 was pretty popular advice to solve all kinds of 'problems'. Usally 0644 is a sane default for web stuff.
Yep, that's exactly what he meant: Here's how to get out of vi when you get stuck there, and here's how to undo the stupid thing you just did to try make your website work. For web stuff you usually do want 0644, or 0664 if the files are owned by your user account and not apache.
chmod 0644 is indeed bad advice in ~/.netrc. Similarly, [Esc] :wq is not too helpful at a bash prompt. If you don't know the difference you're not yet ready for the magic post-it note.
My point is that if you don't understand what chmod 0644 does, you probably shouldn't use it as general advice. chmod 0640 would be better general advice, but it's not a fix-all.
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>
Reading title I thought that it will be about helping people switch to a different text editor. One that is not an improved version of a text editor from 70s.
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.
I'll first admit I'm a worshiper of the Church of Emacs.
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.
Emacs is definitely difficult to exit from. The difference is emacs usually isn't the default/fallback EDITOR on the system, so you rarely get dropped into it unknowingly/unexpectedly.
Also: Emacs is rarely if ever used in the terminal today, and exiting it through the standard desktop protocol ([X], Ctrl-[Shift]-Q, Alt+F4, ...) always works.
I use emacs in a terminal all the time (usually in a tmux session, actually). That's how I learned it (in pre-GUI days) and so it feels pretty natural. I never use the mouse with emacs, even in a GUI session.
Note that GUI emacs doesn't mean using a mouse. I use GUI emacs but almost never interact with it with a mouse, I just have a server-enabled emacs running fullscreen in one of my virtual desktops.
We get so many people using it in terminals in #emacs. Obviously there's no way to know how many people are not using it in a terminal because they won't be asking GUI-specific questions. I and a few others do try to discourage the terminal users and nudge them towards the GUI which is more featureful, but some people really want to use a terminal at all costs.
I don't think that's true. System administrators will happily use it in a terminal. I'd often deliberately run emacs -nw when something requires a quick edit and the GUI would be imposing.
My anecdotal experience has been that no matter how many times I'm told how to exit Emacs I can't remember but every developer I have taught '<esc>:wq' to has remembered it after one or two times telling them what it is.
A MIDI foot controller isn't a musical keyboard (though such things do exist, mimicing organ pedals). It's used for MIDI program changes. I have a MIDI programmable guitar pre-amp, and so in combination with this pedal, I have access to various amp settings just by stepping on various buttons.
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).
C-x C-e evaluates the Emacs Lisp expression before the point. This gives the same result as the much more obvious M-x kill-emacs, but with the added fun of writing and executing Lisp directly in whatever buffer you're in. So to close the editor, we've written some code in a weird ancient language into some random text file, fired up an interpreter that's probably so portable you can run it on a 1980s toaster, and executed an expression which we had to make sure was wrapped in those vile parentheses everyone loves to hate.
Straightforward.
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'm having a go at using Vim full time after years of dabbling.
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.
> It looks like developers in Ukraine, Turkey and Indonesia are getting stuck in Vim quite a bit: it makes up a larger portion of their Vim questions than in any other country. In contrast, in China, Korea and Japan the fraction going to this question is one-tenth as much. That might indicate that when developers in these countries enter Vim, they usually meant to do so, and they know how to get out of it.
I'd say no. I work in Japan and here everybody uses a Japanese equivalent of StackOverflow. This conclusion is so wrong.
How is the conclusion wrong? If there is a cohort of developers in Japan that do use SO, then the statistics are still valid even if all developers in Japan don't use it.
Because the traffic is based on % of all vim visits. This means, if less Japanese visit, the share they have in the total % of all vim visits is also less.
I'm going to be perfectly honest, I got trapped like this in vi, decided that anything so complicated to exit out of wasn't for me and stuck with nano ever since.
> It looks like developers in Ukraine, Turkey and Indonesia are getting stuck in Vim quite a bit: it makes up a larger portion of their Vim questions than in any other country. In contrast, in China, Korea and Japan the fraction going to this question is a tenth smaller.
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.
IIRC, they had regulations about banking security that mandated some IE6 ActiveX plugin. They are just now, or just have, coming around to changing that.
> It looks like developers in Ukraine, Turkey and Indonesia are getting stuck in Vim quite a bit: it makes up a larger portion of their Vim questions than in any other country. In contrast, in China, Korea and Japan the fraction going to this question is one-tenth as much. That might indicate that when developers in these countries enter Vim, they usually meant to do so, and they know how to get out of it.
That's funny because I feel that exiting vim is easy. On the other hand, exiting from nano is a nightmare and makes no sense to me - To make matters worse, it's difficult to find info online because it's hard to explain nano's confusing interface with keywords. I hate how git made nano the default editor on Ubuntu. Every time I install git, I have to remember to change the configs to use vim as the default.
Actually it's exiting when you have unsaved changes which is confusing, the second prompt that comes up makes no sense to me. Also it shows a caret ^ character to represent the ctrl key which is confusing.
Shift-key slippage kept biting me so hard that I gave up and bound an unshifted key to command mode (personally `nnoremap <Space> :`). No more accidental :Q.
Am I the only person who clicked on this link hoping it would provide guidance and help on how to switch to a different text editor after being "poisoned" by vi for so long?
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.
The last graph shows, of people who get stuck in vim what language they use the most. This means this could just be a graph of the most used programming languages. eg if there is a uniform 10% probability that anyone will get stuck in vim. I would find it interesting to see a graph that show what percent of each language's users get stuck in vim.
The latter is indeed what that graph is showing: what percentage of each language's users get stuck in Vim (or more precisely what % of their Vim visits are to that question). It's not being confused with the most used programming languages.
Assuming it takes an average of 1 minute for someone to look up the answer and quit Vim, the readers of this question alone spent a total of 2 years looking up how to quit Vim. Whether or not it was a good design choice, it goes to show how much of people's time and energy is at stake when you make software at enormous scale.
It's interesting to observe that I am the only person to have spoken up about alarm bells going off when it got to the part about Ukraine being the place that visits the Stack Overflow WWW page the most. No-one in this discussion, or in other discussions that I have read, has yet said:
> 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.
I remember getting stuck in emacs as a teenager on my only computer and having to just hold the power button down to get out because I had no way to search the Internet for the exit command. Haven't used emacs since. Good times.
I can still remember sitting at a VT-220 in the college computer lab with my first Unix account (on a MIPS DECstation of all things), running emacs[1], getting stuck, and then sheepishly having to yank the power on the terminal to fix things.
[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.
When using a "ZZ" in command mode, I accidentally hit a ctrl-z every now and then. It took me a while to finally figure out that "fg" in the shell will bring the suspended vim session from the background to the foreground, so that I didn't have to kill the process.
Not that it entirely matters, but those country/prog. language stats are useless since they don't normalise to site-wide traffic (or at least they don't seem indicate they do).
Anecdotally, would get stuck in Vim having thought that the override command was :!q instead of :q!...
I remember my first dealings with Vim. It was awful. I kept having to hit the X button and reconnect, only to find that nothing saved. I've since switched over to nano and prefer it over any editor in Linux. Easy to use, easy to save. That's how it should be!
Sadly, nano has (had?) the nasty habit of adding invisible characters on save (some combination of \r \n). I once almost got into a fist fight with a coworker over this, until he let me show him that his modifying the config was why some application kept crashing on restart.
Good to know miles. I've used VIM, but it is more strict in editing and takes a while to get to know. nano is just a plain editor. I'll keep a lookout for it if something doesn't work.
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.
sighs wistfully I still remember the first day I was able to exit vim without looking it up. It's right up there with that one time I wrote a function that compiled and worked on the first try.
Long, long ago in my programming infancy, I memorized a three-word ritual that has saved me countless hours over the years. It should be taught to freshmen CS students everywhere: Colon Queue Bang.
Add in the bonus confusion that you may not have even been trying to run vim, and in fact may not know what it is (hey, everyone's a beginner some time), but have landed there due to a default $EDITOR value.
[EDIT] also, a typical mid-level computer user's tendency to slap "ESC" when panicked. Ha!
I dunno if it's actually vim or some variation on it, but it is the default on, for example, Arch Linux, although I believe most other distros dropped me into it as well (e.g. git commit / rebase -i).
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.
If vim opens and that's the first thing you try, then it'll work, yeah.
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.
On the Mac, the escape key has been used forever in dialogs as a surrogate for the Cancel button or for dismissing dialogs where the results are non-destructive.
If you hit ctrl-c then you are no longer in insert mode (ctrl-c acts like esc for some reason), so no, it won't add anything to the buffer and ":q" will get you out.
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.
<ctrl>-c is not a vim command. It's a universal terminal command.
<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.
the hardest thing is, after their experience in trying to quit vim is then trying to tell them "No, it's actually quite an awesome editor....no it's not a piece of #$%!%.....no truly, it's good! .... oh you're back in your nice safe IDE, ok ok, we'll talk later" :)
Proper IDE is fine, but then you switch to/embed another language and suffer. Btw, my colleagues often fail to perform simple tasks with proper IDEs, e.g. grepping entire project folder, not only files added to the project. Or moving through sources effectively, leaving interesting checkpoints in splits. Or respecting sw/ts/et settings per-file. Or formatting a table. IDEs are too high-level for these things, because they can refactor-omg-rename for ideally correct static language sources.
I'm somewhat amazed but mostly amused that the Vim developers care so little about user experience that they continue to ignore that people have trouble with exiting their tool and refuse to adapt to a more expected convention for exiting it.
VIM works in a certain way. Once you understand it, the mechanism for exiting fits in just with the rest of the patterns. Why should they create a special case for exiting versus other operations? "Why is it so hard to search? Use ctrl-f instead of /" "Why is it so hard to cut and paste?" "why is it so hard to move the cursor?" You'd have a different editor if you changed the keybindings.
Vim's defining feature is the keybinding grammar, so it would no longer be Vim if you changed it.
vi's defining characteristic, which vim inherits, is that it is _modal_. That means that it has modes, like input mode (where what you type is added to the file), and command mode (where what you type are commands to the editor).
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.
It literally everytime you boot the first screen tells you how to quit and get help. So..read the screen that comes up Everytime? If you try Ctrl c it tells you it's :q.
> developers are often dropped into Vim from a git command or another situation where they didn’t expect to be, and they run into it infrequently enough to forget how they solved it last time.
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
Because it's an editor, and if it just quit on me every time I mistyped Ctrl-C just because you can't be bothered to type the right command, I would be quite angry.
Since I switch between Mac OS X, Windows, and Linux hosts, accidentally typing ctrl-c when I meant to type cmd-c (copy outside of Terminal) isn't such an infrequent error. I'm thankful that ctrl-c isn't mapped to quit without saving.
Well, and my GUI editors don't respond to single-letter commands. It would violate my expectations of their UIs if they did. Similarly, in vim, I expect ctrl+q to send an XON signal to my terminal emulator...not to quit my editor.
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.
> Whatever logic currently used to print the 'Use quit() or Ctrl-Z plus Return to exit' message could also... quit the REPL in the first place, right?
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.
There is no special logic behind it. It just prints the value of the variable with the name "quit", the same way it would print the value of the variable "foo" if you typed "foo".
The repl's basically supposed to help you write a program by matching the behavior of Python itself. What if I've got a variable called "quit" and I want to check its value?
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.
> 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.
quit is not a piece of repl functionality, it is a python function that will exit the repl when called, with a string representation that gives that message. If I set quit = 1, or if I define my own quit() function, I don't want to have to be continually fighting the repl in order to inspect its value.
That was not lost on me. They're wrong, and kinda mean TBH, but someday someone will make a pretty good language, with a really helpful compiler/interpreter and will have the viral-fu to get it in use
Plenty of good reasons for ^C not to quit, mostly having to do with the rest of the Vim interface. Off the top of my head, first ^C is for cancelling actions, second ^C is very close to ^V, which is used for block-select, and very close to ^X, which is used for auto-completion, and very close to ^D, which is page-down, and quitting by mistake would be super frustrating.
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".
In both cases, the program doesn't know what you're trying to do. It knows what you're probably trying to do. That's not enough.
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!
You might expect it to quit immediately, but most Vim users don't (for example I have a habit of using Ctrl-C to exit insert mode). When you travel to a foreign country you shouldn't expect everybody to speak your language.
What if you're normally a Windows user and you pressed CTRL+C trying to copy something out of the terminal? You haven't written to disk in a while, and then poof.
Wait, this is how I got so stuck my first time in vim! It sets you up for a whole string of problems in a row:
- 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.
Weelll. The problem is that the "quit" command has an insert mode key in it. So it's quite possible to get stuck like a poster above says- enter macro recording, then insert mode, then write the letter "t".
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
See all that whitespace? It's very hard to think the colon goes to the "Type" bit.
So you can get stuck in a dubm situation but it's not terribly easy.
See all that whitespace? It's very hard to think the colon goes to the "Type" bit.
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.
Alright, but if we're being so scholastic it should be said that you can misinterpret any set of instructions and in this case, squinting at the command line a couple of times to make sure you got the command right is all it should take you to get it right.
Cute, but no. When you enter insert mode, the "welcome screen" disappears. So if you can see the instruction telling you to type ':quit', then typing :quit will work.
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.
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
disappears as soon as you enter insert mode (or really interact with Vim at all). If you're in insert mode, you don't see this. So if you see this, typing :quit will work.
Of course, yes. The above commenter mentioned insert mode and ctrl+c which is why I was missing that you particularly were talking about this one screen.
And worse vim is often the default EDITOR or software's fallback in case no EDITOR is set, so you get dropped into a vim edition buffer seemingly randomly.
I'm pretty sure that I've never seen any OS/Linux distribution set default EDITOR to vim. If EDITOR is set to vim, then someone must intentionally did that.
Right. Many programs react to an unset EDITOR variable by assuming vi though. This makes sense, of course, as virtually all systems are going to have some implementation of vi installed. Even the almighty ed tends to be missing from the default install of some recent Linux distributions.
Maybe someone should file a bug to them? I don't think vim is a sane default value for EDITOR, but I have no idea whether there's any sane alternative on Windows.
Coming from the Windows world, I am happy that Ctrl+C doesn't make assumptions and quit. Imagine attempting to copy something and having your file close without warning.
Ironically, in vim, where the terminal is in non-canonical input mode when vim is in the foreground, it is not keyboard interrupt. (Nor is it in most modern shells, which also use non-canonical input mode in their command line editing mechanisms.)
Yep. Apple got this one right with the Cmd key. Much saner than the context-dependent hijacking of the control key with its long-established conventional usage.
I don't particularly like vi, but as a intermittent user for 20 years, I don't like it to be changed just because a few junior front end developers (ok a million) think it's hard to use.
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...
As a sysadmin, this drives me crazy. I log into a lot of systems I didn't set up, and then I press the key at the command prompt to bring it up in an editor, or invoke something that uses an interactive editor, and its nano. I have to exit it, export EDITOR=vi and do it again. I don't even like vi as a standard editor. I just expect the system default of vi, and nano is painfully underpowered. I'd even adapt to it running emacs, but it's like getting a nerf hammer every time you need a real one when the system pulls up nano by default.
Or as an emacs user, we deal with a lot of weirdness by modern standards. But when someone asks for a random change, it's more a matter of, "sure, knock yourself out."
One could easily relate this to burkaman's comment in this thread on the most viewed question (how to undo a git commit).
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.
Vim has a steep learning curve and making that one thing easier isn't going to make that curve any easier to climb. Powerful tools require documentation and looking up how to quit is the first task of many to use any of vim's power.
Not everything has to be easy to use, some things benefit from not being obvious.
I think this is a poor argument. If it's the one singular thing that's frustrating this many users, that's a reason to focus on particular on fixing it somehow. You also need to take into account that most users encountering this problem are not deliberate vim learners: they ended up in vim by accident.
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.
There is a common convention, though, which is: don't use modal interfaces, modal interfaces are bad.
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.
Modal interfaces are bad; yet it's what differentiates Vim from everything else, and thousands of people actively enjoy using Vim.
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."
> 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."
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.
How is having an open menu that blocks input NOT a mode? Using your arrow keys will move menu items, enter will select menu items, letters will also often switch menu items attempting to find a menu item with that letter, and getting out of it requires additional clicks or hitting escape.
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.
> If you took the modal interface away from vim, you wouldn't have vim anymore. If you don't want a modal interface, don't use vim.
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.
> you don't have a choice as to which editor to use
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.
> 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.
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.
SSHing into a server implies a basic level of technical competence. The user presumably already knows cd, mv, ls, and family. Why would expecting the user to know a touch of VIM be out of place?
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
It's maybe impossible to create a tool that's relatively small, intuitive, and for experts. Vim is relatively small and for experts.
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.
> "refuse to adapt to a more expected convention for exiting it."
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)
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).
Actually, no. vim runs with the terminal in non-canonical input mode. Control+Z results in a SUB character being sent to vim. vim, in turn, knows to suspend itself when it receives that character (in visual or normal mode).
No, applications can and do trap either ^z or the signal it generates (not sure which). I'm a vi user [0] but I'm pretty sure emacs requires ^z^z to STOP.
emacs stops on a single ^z. You can trap it based on SIGTSTP though (Terminal SToP, a distinct signal from SIGSTOP, which I don't think can be trapped).
The GUI version can be exited from in the same way as any other GUI application. If run from the command line, there is no standard way to exit (nano? emacs? joe?)
For gvim, the X works as expected but what would be a more expected convention from exiting a cl text editor be? Most long running cli tools people are used to are read only and have just a few keys for different views and they tend to use 'q' or 'Esc', any single key isn't an option for a text editor. If they're in normal mode, Ctrl-c does give the message "Type :quit<Enter> to exit Vim" but I'm guessing most people don't notice it or think the ':' isn't part of the what they have to type because they don't now commands start with it, I would change it to "Type ':q<Enter>' to exit Vim". But people tend to accidentally leave normal mode by trying to type other things, so the Ctrl-C message isn't always helpful.
Vim is a modal [1] editor that runs in a console. From those two points onwards you're already a few orders of semantic magnitude away from "more expected convention(s)" so there's really no point trying to fit it into a context it was never meant to fit in the first place.
It’s tremendously important to realize that Vim comes from a VERY long line of text processing utilities that stretches back over a half a century. Vim is the result of constant iteration on a set of design ideas and conventions that predates it. `Q` for `Quit` is one of the oldest Vim commands, tracing its roots all the way back to the `QED` editor of the 1960s[1]. Changing it now would be foolish.
While I love vim, your argument holds no water. By your argument, it's foolish to change anything at any time, because everything traces its roots back to "something."
I think the real problem is that vim is the default editor or people are writing tutorials and using vim. Asking vim devs to break the whole raison d'etre (modality) is kind of ridiculous.
In my opinion the problem is more, that console beginners are told that CTRL+C is a magical bullet that will save them from any obstacles they might encounter in the depths of the cli.
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 pretty much written by one guy, and like Linus he remains consistent in what his creation's user experience should be. VIM is not meant to be easy to learn, it is meant to be easy to use one you've invested in learning it.
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.
the experience of trying to get up-to-speed with the original vim codebase in order to contribute to it is apparently quite awful. So bad that a bunch of folks started neovim. Anyone with the frustration tolerance to go through that gauntlet is unlikely to be very new-user-UX focused.
What interactive terminal programs exit using ^C? Nano doesn't, top doesn't. There is no standard for interactive terminal programs. Furthermore ^C doesn't fit with the rest of vim's control schema, so you wouldn't really be doing anybody any favors in the long run.
> 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.
Perhaps an alternative is a "first run" mode which could do something like ask "did you intend to open vim? Y/N (answering N will close vim)". If you answer Y then you get a lesson in closing vim, if N then you always get the "first-run" mode until you answer Y?
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.
There has been a resurgence of use since the popularity of Spacemacs, and I know several of my peers around my age (20) who use Emacs, including myself.
Ugh, these types of editors drive me batty. Why can't it just be easy to quit? Why, why?! If I absolutely must use an editor in the terminal I use nano.
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.