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. :)
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.
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.
(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.
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.
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).
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.
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.
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.
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.
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.