Vim is the worst editor, except all the other editors
andre.arko.net
andre.arko.net
Yes to the first five words, no to the rest. How many Vim users realize that some of its more infuriating behaviors can be traced back to its predecessor vi, which had to be able operate with a "paper terminal", essentially a roll of paper as a display, without wasting too much paper during editing?
And how do I know this? During my time at NASA designing part of the Space Shuttle, I was obliged to use vi and its immediate predecessor, with a roll of paper as a display. It was bad then, and it's worse now. The difference is there's no longer an excuse.
http://en.wikipedia.org/wiki/Vi#History
Quote: "vi was derived from a sequence of UNIX command line editors, starting with ed, which was a line editor designed to work well on teletypes ... "
In other words, it's vi with a few changes. I still can't navigate while typing, or delete while navigating, or search while deleting. As I tried to remember all those weird incantations that I last used in the mid 1970s, I felt as though I was in a time warp.
Guess why Apple Writer was so popular in 1979 (http://en.wikipedia.org/wiki/Apple_Writer), in spite of its many limitations? I wrote Apple Writer specifically to avoid the handicaps built into vi, which was the default editor in those times. After Apple Writer came out, people would write articles saying things like, "My God! With Apple Writer, you can read files, write files, type, navigate and search without having to change modes! How did Lutus do it?"
The answer is simple. Apple Writer wasn't so extraordinary, but I wasn't mentally crippled by the vi code base or method of operation, and I wasn't averse to exposing people to new ideas. But you know what? If I was told that people would still be using vi thirty-four years later, and boasting about its wonderfulness, I would have fallen down laughing.
Even pico and nano are easier to use, and they're desperately weak.
I shouldn't complain. Apple Writer made me a multimillionaire through the simple virtue of not being vi, and little else. I should thank you people.
No, to switch from entering text, to deleting text, to searching for text, to copying and pasting text, to saving a file, to loading a file, all require switching modes. Let's be honest.
> By making that compromise you make the system faster and more powerful ...
Having to enter additional keystrokes, a throwback to a computer keyboard that either didn't have control keys or couldn't exploit them, makes editing "faster and more powerful"? Nice reasoning.
You're calling vim commands "modes" to deliberately make it sound more complex than it is.
I want to change to next 3 words. I type 'c3w' - you're saying that's modal - which it sort of vaugly is. I could have done 'v3w' to highlight the next 3 words (something you would do in any other editor). Then I hit 's' to substitute them for something else. No mode involved (other than the selection - which is the same for any editor).
I stand by my assertions - it's up to you to provide the counter examples to back up your claims.
* I am moving the cursor, but I want to enter text. To do so, I need to enter colon, i, Enter, then my first text entry.
* I am entering text, but I want to move the cursor. To do so, I need to type Esc, Esc, then commence moving the cursor.
* If while entering text, I want to do something besides move the cursor, I need to type Esc, colon, then a command letter, then its arguments.
I don't need to "make it sound more complicated than it is." It is in fact more complicated -- more complicated than Apple Writer, now justly consigned to a museum, and more complicated than any modern editor.
> I type 'c3w' - you're saying that's modal - which it sort of vaugly is.
This is getting comical.
> I could have done 'v3w' to highlight the next 3 words (something you would do in any other editor).
No, in any other modern editor, I wold pass the mouse cursor across the desired characters, thus selecting them (any subset of characters or words or paragraphs, and very, very fast). There's a reason the mouse was invented, and it wasn't because it's a cute but insubstantial gimmick meant to pander to the tastes of ignorant, unsophisticated computer users.
In Android, I would swipe my finger across the desired text. No mouse needed.
> I stand by my assertions ...
Try moving beyond assertions -- try locating some evidence, as I have just done. Pretend to be a scientist.
> it's up to you to provide the counter examples to back up your claims.
As I have been doing since this thread started? Read my posts.
You don't type ':i' to get to insert mode, you just hit 'i'. You don't hit Esc, Esc - it's just Esc (though lots of people remap it to 'jj').
Really these are the two modes I was referring to - you need to move between them, yes, but you'll always be in normal mode except for times you're inserting a bit of text. The way you describe using it is the mindset of everyone who first starts using vim and wants to stay in insert mode. I started that way - but it's not the way vim is used. It's the first thing beginners have to understand - normal mode is where you'll spend almost all of your time.
I don't understand what's comical about 'c3w' - "Change 3 Words". You know what's comical? Reaching for the mouse to highlight 3 words to change. Though, you can make that choice - vim supports the mouse too these days. I used it when I first started on vim - it was a bad idea as it's so much slower than using the commands.
Again, I stand by my assertions; Vim is faster and more powerful - other editors are easier to learn. You still haven't provided a shred of evidence to the contrary.
I think your condescending tone is really unhelpful. I've given you the time and respect you deserved to address each of your comments. It would be honourable of you to treat me in the same way.
I just crafted the above example using the current vim. No memory required. Vim still imitates vi, and vi still imitates 1970. Extremely inefficient, steep learning curve in order not to press readily available control keys.
> I don't understand what's comical about 'c3w' - "Change 3 Words".
First, if you happen to be entering text beforehand, the number of characters required to select three words isn't three, it's five. Second, it's comical in modern times because there are much easier ways to select an arbitrary number of words, readily available ways, ways that don't cost any more than vim does, ways that are available on the machines owned by vim's advocates -- excuse me, living advocates. Machines that have keyboards with control keys.
On a modern machine, if I want to select three words, or 2 1/2 words, or 3 1/2 paragraphs, I glide the mouse cursor across the desired text. And to do so, I don't have to enter a special mouse mode first.
This conversation is funny for the same reasons that a conversation about a horseless carriage is funny. No, there's no miniature horse hidden in there -- they did away with the horse entirely. I know it sounds fantastic.
> * I am moving the cursor, but I want to enter text. To do so, I need to enter colon, i, Enter, then my first text entry.
That's incorrect. You can just press 'i' to enter insert mode in place. Or upper case 'I' to have Vim enter insert mode at the end of a line. Or upper case O for insert mode at the beginning of freshly inserted line below the current. Or 'a', 'A', 'c', 'C' and many other's for other kinds of movement/change+enter insert mode combos.
> * I am entering text, but I want to move the cursor. To do so, I need to type Esc, Esc, then commence moving the cursor.
No, the arrows work (should work, may be a problem on some terminals/terminal emulators, but that's common for console editors) in insert mode. No need for <esc> (and it's single <esc>, not double, anyway) if you want to move by a few characters. Ctrl+<arrow> works in insert mode, too, so you can move by words. You lose prefixes and other kinds of movements though.
> * If while entering text, I want to do something besides move the cursor, I need to type Esc, colon, then a command letter, then its arguments.
That's only true if the command is not bound to a sequence of keystrokes. If it is, it's frequently as efficient to type as in modeless editors, for example going to a certain line in Vim is done with <esc><number>G, while in Emacs it's default binding is M-g g <number> <enter>. If the command is not bound, both <esc> : <command> <args> <enter> and M-x <command> <enter> <args> <enter> beat navigating through menus with mouse in terms of efficiency and that's what they are for, not for the commonly used commands which should be (nv)maped or global-bind-key'ed anyway.
> I don't need to "make it sound more complicated than it is."
Well, you do, as shown above.
> I wold pass the mouse cursor across the desired characters, thus selecting them (any subset of characters or words or paragraphs, and very, very fast)
Well... I would like to measure this somehow.
You assert that using a mouse for this is quicker, but present no evidence. I have no evidence for the contrary, so we can't really argue about this. I personally feel that reaching for the mouse and using it is slower than selecting text with keyboard and that the latter requires less manual precision, which matters to me. You can feel differently and I respect and accept it.
We - Vim users here - can probably show you shorter and more efficient counterpart to any example you'd come up with. That you don't know these more efficient ways is a valid criticism of Vim in itself - which is not a popular claim among Vim users, but I think so - but it's argument for Vim not being friendly to beginners, not for it being inefficient.
It's not common in modern times for any of this to be either necessary or justifiable. But now that we're no longer discussing how inefficient vim is, but discussing tricks meant to minimize its acknowledged inefficiency, I think we're done.
> > I wold pass the mouse cursor across the desired characters, thus selecting them (any subset of characters or words or paragraphs, and very, very fast)
> Well... I would like to measure this somehow.
You can measure it by noticing that most modern computers since 1980 have control keys, and mice, and nearly none of them have vi or vim installed. People have voted against terminal editors with their mice, and with an absolute minimum of keystrokes.
> We - Vim users here - can probably show you shorter and more efficient counterpart to any example you'd come up with.
This is the most astonishing conversation I've had in weeks. I can also show you more efficient ways to push a rock up a steep slope while wearing a hair shirt, but the risk is that some spoilsport may mention that the entire exercise is unnecessary.
I started out using vi. Then I wrote Apple Writer, which was more efficient by far. Then I dumped Apple Writer for a more efficient editor that supported a mouse. Then I dumped that editor for a better one, ad infinitum. Lazy? You bet -- I have better things to do with my time than remember vim's arcane ways to avoid the use of the keys that are on all modern keyboards, or the pointing devices that have become popular since 1970.
Any of which? Please, be more precise. You mean that it's not common for certain keys to be mixed up in console applications? Please...
> You can measure it by noticing that most modern computers since 1980 have
Oh well, you have a curious definition of measurement then.
> some spoilsport may mention that the entire exercise is unnecessary
You mean editing text is unnecessary? Or what exactly?
> I started out using vi.
I came to Vim after using Visual Studio, Komodo IDE and some others...
> Then I dumped Apple Writer for a more efficient editor that supported a mouse.
...then I dumped it in favor of Emacs, which supported much better scripting language.
> the pointing devices that have become popular since 1970
You still didn't provide any kind of evidence that editing with mouse is faster than using pure-keyboard interface. Or do you believe that it was text editing that drove mouse adoption? Are you completely sure that it was working with text that demanded mouse and made mouse popular? Is it that impossible to believe that once mouse became popular thanks to other kinds of programs the editors started to support it?
I'm glad you wrote your Apple Writer. I'm less amused by your mistaken beliefs you insist on advertising in every Vim related thread. You may be a reason I finally check out this script for not showing HN comments of specific people.
How about the direction of computer history? Vi was superseded by Apple Writer (and other editors, some of them better) that supported the existence of control characters, those editors were superseded by editors that supported mice, and those editors have in turn been improved on to the present day. Do you really think this was all homage to empty fashion, and that modern editors require more work than vi/vim?
Apart from that, it's been proven over and over again that pointing devices improve the efficiency of text editing, compared to an editor that only has control characters to guide the process, and much less so for editors like vi/vim that don't have the advantage of control characters.
Reference: http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
Quote:
* Test subjects consistently report that keyboarding is faster than mousing.
* The stopwatch consistently proves mousing is faster than keyboarding.
End quote (BTW the above is a famous quote by a friend of mine from the early Apple days).
Remember that the above comparison, and all modern comparisons, only compare mouse-dominated use with keyboard-only use for keyboards having control characters -- none of them take on the added burden of vi/vim's modes, which result from the absence of control characters on early keyboards.
> I'm less amused by your mistaken beliefs ...
I just proved that my views aren't beliefs, they're backed up by research, and they are not mistaken. You are not arguing in good faith -- you have no evidence for your position, but you have strong feelings. Not a situation conducive to generating light, as opposed to heat.
"In the early (pre-release) days of Lisa, we had command keys instead of pull-down menus. One of the primary reasons we abandoned command keys was the difficulty of coming up with fixed definitions that could be easily transported from application to application. Users were constantly confused."
"It takes two seconds to decide upon which special-function key to press."
No, it doesn't. When my cursor is on a function name I want to change in vim, I type 'ciw' and then word is gone and I'm in insert mode replacing it. There's no 2 seconds about it.
Your research doesn't apply to this scenario and you know it. But it's fine - you do it your way, we'll do it ours. There's no problem with that.
> We’ve done a cool $50 million of R & D on the Apple Human Interface.
Relevant to anything? I'm supposed to feel intimidated by a heap of dollars, right?
Where are the exact experiments described and results presented? Where is the paper with all of these details? I searched the web, but I couldn't find it. Perhaps I need to pay some $.
There's a commentary on this piece by Jeff Atwood, which points out the fact that the article is seriously old and that understanding of the issue has changed in the meantime. I can't say for sure, but from what little info there is in the article it seems that way - I'm not going to argue that there are efficient mouse-centric interfaces being designed and used or that the mouse should never be used as an input device. What I'm saying is that there is a least one keyboard based interface for text editing which is more efficient than equivalent mouse based interfaces - for the most part. I admit that there may be some tasks easier to accomplish with mouse (although we didn't see them yet), but that doesn't invalidate my argument, especially because if they exist, then Vim allows for mouse usage to do them.
The AskTog article is linked to from a page on Plan9 editor, Acme - it's another piece which uses ancient version of vi for comparison. It's so frustrating to see people completely ignore all the development in the Vim interface because it's early versions were much worse. And they are prominent people in our industry, too. It's just sad.
I now have some idea about what makes editing efficient. I may even create the next AppleWriter, although I think Chris Granger already does a good enough job. Almost nothing lutusp said turned out to be true, but the thinking I put into this discussion let me realize some important things about editing. So, on the whole, I don't think I wasted this time.
However, any more than this I feel would be a waste.
Remember with no .vimrc vim defaults to vi emulation mode for historical reasons. ":set nocompatible" to fix that, compatible mode turns off a lot of the wonderful Vim features us Vimmers have come to love.
> * I am moving the cursor, but I want to enter text. To do so, I need to enter colon, i, Enter, then my first text entry.
... you can enter insert mode a variety of ways, i, I, o, O, a, A, etc -- each has a specific meaning.
> * I am entering text, but I want to move the cursor. To do so, I need to type Esc, Esc, then commence moving the cursor.
... you just hit escape to go back to normal mode, which generally pay dividends on that single keypress with an better group of movement keys (move by word, sentence, paragraph, tag, search, etc). Or just use the mouse (works perfectly well, doesn't even change the mode, set mouse=a)! If you are in insert mode, you remain in it, same for normal mode!
> * If while entering text, I want to do something besides move the cursor, I need to type Esc, colon, then a command letter, then its arguments.
... actually, vims insert mode has many features for editing without leaving it for convenience, C-W, C-U, C-J, C-M, C-N, C-P, C-R and a bunch more for deleting words, lines, interacting with registers, etc.
> No, in any other modern editor, I wold pass the mouse cursor across the desired characters
Sure, and you can do that in vim (console or gui, works in both with mouse=a), but some of us (myself included) consider this an inferior way to select 3 words via sloppy indirect abstracted pixel pointing. Not to mention pulling your hands off the keyboard... to the mouse, then back again re-seating to continue typing. Mice are for FPS games, not selecting text!
EDIT: Even if Vim someday dies (decades from now maybe), modes have spread, I use modes in Word, Outlook, Visual Studio, Xcode, Sublime, Eclipse, Firefox, Chrome even on my ZSH prompt. Once you get used to modes based editing, it is an amazing addition to any editor or GUI, and people keep creating plugins so Vim mode lives on! Editing text hasn't change radially, because text hasn't changed radically... the reason emacs and vim live on is because of fitness for the task at hand, editing text.
Thereby allowing vim to become almost as efficient as a modern editor, specifically by disabling those traits that make vim vim.
> Once you get used to modes based editing, it is an amazing addition to any editor or GUI ...
That would be why why modern editor designers make sure to include a modes mode, to appeal to time travelers visiting from earlier times. Yes, I'm kidding -- no one wants an interface that requires any more than the absolute minimum of either keystrokes or arcana unique to one editor.
> ... the reason emacs and vim live on is because of fitness for the task at hand, editing text.
As to the thread's topic, this is false. Vi and vim aren't as efficient as a modern editor, which is why most current computer programming activity uses tools designed with a modern computer -- and a modern computer user -- in mind.
I could easily write an editor much more efficient than vi/vim -- I know this because I did, and it became very popular -- and its advantages would become obvious to all but True Believers.
As soon as someone invented the control key and its purpose, and well before Douglas Engelbart invented the mouse, the retirement clock started ticking for vi and vim. It's still ticking, but it seems not everyone can hear it.
Please define a mode and define mode switching. It's obvious we use different definitions for those and so we can't have meaningful discussion.
If I'm entering text, I cannot move the cursor. Mode one.
If I'm moving the cursor, I cannot enter text. Mode two.
If I'm using a modern editor, these modes are not present -- if I want to move the cursor, I press the appropriate keyboard keys. Instead of pressing a letter key to insert a letter, I press the up-arrow key to move the editing cursor, without any preliminary mode-switching keys. This means an absolute minimum of keystrokes, and because there are no modes, the letter keys always insert letters, and the arrow keys always move the cursor.
All before beginning to discuss the mouse or other pointing devices, methods that have existed since 1963 and have been in wide use since 1980.
Any questions?
The reason I ask is because in vim, I can move the cursor with my arrow keys when I'm in insert mode, and if I wanted to, I can select blocks of text with my mouse, without pressing any key to change mode.
In addition to those features I can move about more efficiently without moving my hands from the keyboard, by changing mode. I touch-type, and I write for a living, so this is quite important to me, but assuming the features you mention are the most important ones to you and that you don't want to change modes, you can still do the things you say you can't. Well, I can. Not sure if you can, but I'm fairly sure it's not due to any limitation of vim. I'm curious how you appear to be mistaken in some very basic facts.
Guess why so many people still use Vi(m) and not Apple Writer.
[1]: Was really pleased to bump into your article on Examples in Math the other day.
That's easy to answer -- as astonishing as it may sound, people are still using vim. Some of them might even think it's natural to have to use twice as many keystrokes as are required on a modern editor, even another command-line editor, to switch from editing to navigating (as just one example).
> I'm not sure who you're trying to save here, the bunch of us seem to be mostly happy with what is really the worst editor we can get except all the others.
Yes, except that that is false. Any meaningful comparison is so obviously against vim that I feel like I'm trying to dissuade True Believers from an irrational belief.
Or tell me about any editor where the same amount of keystrokes get the same job done.
Do you also write Fortran? You may or may not be surprised to learn that I have nearly identical debates with diehard Fortran programmers who try to argue that Fortran is anything but a way to support a vast amount of legacy code that no one wants to rewrite (for very good reasons).
Fortran is not the right tool for the job. It once was, but now there are many programs of high economic value that for all intents and purposes cannot be rewritten, for example all the FAA code behind the air traffic control system, as a result of which Fortran will be with us for decades to come.
But no one voluntarily writes new programs in Fortran, at least not if they expect to remain employed. That's true, but try to tell a Fortran programmer this.
Those debates have a lot in common with this one.
My reason for engaging in both debates to to save young programmers from picking up a museum piece without being aware of its legacy status, and thereby crippling themselves and their careers.
I would not say I "write Fortran" (given that soon to be father in law does, and I would be an embarassment to his competencies) I am familiar with it, and even so would not argue maintaining huge truckloads of legacy code. There does need to be lines for when you "burn it down" or realize that you've been accumulating technical debt that just maintaining compatibility for and of is only contributing to. I would not say that modern vim falls under this category at this point in time.
In today's terms, the above "without wasting too much paper during editing" argument translates into "with as few keystrokes as possible". In some situations, I definitely find my ability to type (or in general, to edit text) to be the bottleneck in getting things out of my brain and into a file. In these cases, Vim allows me to trade a bit of brainpower for efficiency in editing, which is great.
Other times, I'm being held up because I'm not sure what to type, but I prefer to do creative thinking away from the keyboard, so Vim is neither here nor there in those cases. So basically, the historical argument doesn't make sense for me; do you have any specific issues with Vim?
Sure, no problem:
* It's still a command-line editor. Just like vi.
* To perform multiple operations, like moving the cursor around, entering text, deleting text, searching the document, saving and loading files, requires you to switch modes. Just like vi.
* It cannot take advantage of the modern computing environment -- mouse navigation, different fonts, text styling, page layout, or anything else. Just like vi.
* No clipboard support -- all copying and pasting operations, apart from being another example of bizarre vi incantations requiring the recall of a raft of magic characters, is within vi/vim and disregards the system clipboard.
I can say this in vi/vim's favor: it's a step up from ed, its predecessor.
> In today's terms, the above "without wasting too much paper during editing" argument translates into "with as few keystrokes as possible".
No, actually, in the vi days, to save paper one had to enter more keystrokes, not fewer. When I wrote Apple Writer, former users of vi were astonished by how few keystrokes were required to accomplish things.
> do you have any specific issues with Vim?
Just one. It doesn't belong in modern times, it belongs in a museum.
Anything at all. Kate. KWrite. Gedit. The programming editors built into Netbeans and Eclipse. My own (free) program Arachnophilia (http://arachnoid.com/arachnophilia), a sort of a descendant of Apple Writer, but much improved and with support for many document types. Essentially anything.
All the above choices take advantage of the modern computing environment. That by itself sets them apart from vi/vim.
I would choose VIM over Gedit simply because remote servers tend to have vi/vim installed out of the box, not to mention the fact that Gedit is to me not really all that great (perhaps a bit better than M$'s Wordpad).
VIM is my default editor for sysadmin work; for coding it's Eclipse for server-side and Aptana for client-side (which I guess is Eclipse under the hood, just not as bloated).
You're suffering from a hidden assumption -- that an editor can only be a programming editor, can't be many different things without degrading its usefulness as a programming editor.
All these operations, except entering text, are available from "normal" mode which is the default mode. This is factually incorrect that you need to switch mode to delete something, or save a file.
Based on simple probability, the chance is better than 50% that I was using vi before you were born.
How is calling you young, saying you have your entire life in front of you, an ad hominem? Except possibly to suggest that you have a quota of mistakes you need to go through before you become more efficient at avoiding them?
That's not what you said... you said he was too young to know vi/vim better than you. If you haven't used it in 30 years how would you know vim any better than a younger person? Why would age have anything to do with recognizing the benefits and drawbacks of various text editors? My grandparents barely knew how to turn on a computer... they wouldn't try to teach me that notepad is a better text editor than vim. I'm not discounting your experience (you definitely have more than most people here) but your arguments here could be better.
At this point you have two choices. You can locate where I said that and quote my words directly, or you cam post your apology for making a false claim in this public forum.
To cut to the chase, I never said what you claim, your claim is false.
Ah -- I just figured out why you can't quote my words directly, to discover that I never said what you claim. You're using vim to compose your reply, and vim is so damned inefficient that the task of accurate reporting is consequently entirely beyond your energy or patience.
> If you haven't used it in 30 years how would you know vim any better than a younger person?
False premise, false conclusion. Locate where I said I had never used vi/vim for 30 years.
> Why would age have anything to do with recognizing the benefits and drawbacks of various text editors?
I never made that claim, so I don't have to defend it. Since you have obviously lost track of the thread, the OP used words to the effect that I might be suffering from a neophyte syndrome (not his words). I replied by pointing out that I am hardly a beginner, that in fact I was probably using these editors before he was born. Perfectly apt reply, one having only to do with experience, not age.
> ... your arguments here could be better.
A non sequitur. Ellen Page could also be better looking, even though that's a bit hard to imagine:
http://www.hdwallpapers.in/walls/ellen_page-wide.jpg
Summary. You need to post real quotes of real words, things people really said. Obviously if you're handicapped by using vi/vim to compose your replies, such trivial actions as copy and paste are -- well, by no means trivial -- so the content of your posts becomes more understandable.
You first. You said:
> How is calling you young, saying you have your entire life in front of you, an ad hominem
Your exact words:
> Based on simple probability, the chance is better than 50% that I was using vi before you were born.
Don't be so obtuse.
If you, like most people, spend most of your time entering text, then it is factually correct that you must exit the text-entry mode to do anything else.
And do you know why this arrangement exists? Because there were teletype terminals and early glass terminals that didn't have control keys. No control keys, no way to exploit their existence. SO there had to be a magic character to switch from text entry to control mode. And the magic character was an ordinary character, sometimes used for text entry, sometimes interpreted as a command prefix.
Keyboards have changed, but vi hasn't. Computers have mice and touch-sensitive displays, but vi can't exploit them. Operating systems have clipboards, but vi can't take advantage of that convention. You know -- don't get me started.
The reason most vim users stick with the keyboard is because using a short key combination to select and manipulate text is measurably faster than moving your hand off the keyboard, manipulating a mouse or touchscreen, and then moving it back to continue typing.
What you see as vim appearing to exploit a mouse and system clipboard is actually Bash and (sometimes) a command-line app (example Konsole) doing so, or equivalent utilities outside vim in a non-GUI level. Those features work with any editor in exactly the same way.
As to using the system clipboard just fine, you can copy text from vim or any other displayed source of text, but you cannot paste it, because it's not vim that's acting, or is in any way aware that text has been copied.
> ... because using a short key combination to select and manipulate text is measurably faster than moving your hand off the keyboard, manipulating a mouse or touchscreen, and then moving it back to continue typing.
Right -- the mouse was foisted on a gullible public willing to suffer a reduction in efficiency in order to have an electronic pet, all against their better interests. And the industry's usually diligent efficiency experts were all bribed to overlook the reduction in efficiency you've just brought to our attention.
As for integrating with the system clipboard, that clipboard lives somewhere (X11, OS-X, Windows System), it isn't magic, and vim can integrate with it in various ways dependent on the OS. On windows for example "set clipboard=unnamed" basically makes vim use the system clipboard, period.
So... not sure if you are lying or misinformed.
I'm not sure if you're just joking or you're just misinformed.
For text editing, mouse is more inefficient than keystrokes
Your evidence for that is provided by the fact that the world eagerly adopted the mouse and abandoned vi/vim and similar programs, based solely on the advantages of modern methods.
Your evidence for that is provided by the fact that I wrote an incremental improvement over vi, one that exploited the existence of control keys but didn't exploit a nonexistent mouse, and, even though it represented no great improvement, I retired on the proceeds at the age of 35. (My program was appropriately eclipsed by better, more advanced programs, that among other things did exploit the mouse.)
> I'm not sure if you're just joking or you're just misinformed.
Wake up and smell the Cappuccino. You are not living in reality.
But, a keyboard-based interface is still more efficient for someone who can put in the time to learning how to use it efficiently (and customizing it to their specific work), and uses it regularly enough to maintain that knowledge. For a lot of people who write code for a living, a text editor definitely falls in that area.
This has been proven false any number of times. It's false when comparing mouse use against a modern keyboard with control and function keys, and it is certainly false for the limited keyboards for which vi/vim was designed, those keyboards that result in vi/vim not being able to exploit control characters.
Source: http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
Quote: "We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:
* Test subjects consistently report that keyboarding is faster than mousing.
* The stopwatch consistently proves mousing is faster than keyboarding.
This contradiction between user-experience and reality apparently forms the basis for many user/developers’ belief that the keyboard is faster."
The above quote comes from a study performed a while ago and repeated ad infinitum since then.
Modern vim uses control characters just fine. Have you used it any time in the last decade?
Because you seem to dance around that question a lot, saying "Well when did I say I haven't used vim recently" whenever someone brings it up, and then saying something else completely wrong that indicates you have no idea how a modern version of vim is actually used.
Assertion: vim has modes.
> This is factually incorrect that you need to switch mode to delete something, or save a file.
Assertion: vim doesn't have modes.
Only one of the above claims can be true. Choose which one you want to defend, and delete the other. But don't try to delete it with vim, or we'll be here all day.
In point of fact, if I am entering text, I cannot move the cursor, search for text, save a file, load a file, or a dozen other things, without first switching modes.
I feel like I'm discussing whether there was a literal garden of Eden with a religious True Believer. True Believers famously make claims they haven't bothered to compare to reality before speaking.
Really?
> Assertion: vim doesn't have modes.
No,it is not an assertion that vim doesn't have modes, it is an assertion that you don't have to change mode to do some things
>I feel like I'm discussing whether there was a literal garden of Eden with a religious True Believer. True Believers famously make claims they haven't bothered to compare to reality before speaking.
Guess who is this True Believer
vim defaults to allowing the cursor keys and delete/backspace.
I mouse around my gvim with my custom font all day long middle click pasting snippets in from the browser.
It's still a command-line editor. Just like vi.
Not sure what the issue is there?
It cannot take advantage of the modern computing environment
gvim/macvim exists. They also give you regular clipboard support. Though I honestly don't get much out of all that, and am happy enough with vim in a terminal, but I understand the motivation.
To perform multiple operations ... requires you to switch modes
Vim is modal, yes, but what is the specific disadvantage of that? That it has a learning curve? Mode switches are generally single key presses, so it's not exactly onerous once you know what keys to press. Equivalents in "modern" text editors require use of the mouse, which while being much easier to figure out, is also much less efficient. Using the mouse, though just taking a bit longer each time, is enough for my brain do a switch and focus on that action instead of the code - unlike the vim mode switches I do all the time without thinking.
No, actually, in the vi days, to save paper one had to enter more keystrokes, not fewer
That sounds plausible, but not all that relevant to how one uses vim now.
former users of vi were astonished by how few keystrokes were required to accomplish things
Also irrelevant. Vim's text objects, which basically offers you a vocabulary for text manipulation, has no match and will generally allow vim to win in practically any keystroke comparison. It's not clear how well you know how to use vim, if it all, though you've clearly used and hated vi in a past life :).
So Steve Jobs was wrong to visit Xerox Parc, be impressed by what he saw, and create the modern computer?
> Vim is modal, yes, but what is the specific disadvantage of that?
It is less efficient. But you are now obviously trolling, posing arguments that no rational person could possibly accept. "So, a few more keystrokes for each command, repeated for each such command. So what? Are you in a hurry to get somewhere? Do you want to live forever?"
I said no such thing. I said a keypress is more efficient than alternatives, and thus more efficient and faster.
Please reconsider who an external observer would mark as a troll in this conversation. But in fact, I don't think you're trolling, you just hate vim, and that's fine. And I like vim, and that doesn't make me a troll I hope.
> * To perform multiple operations, like moving the cursor around, entering text, deleting text, searching the document, saving and loading files, requires you to switch modes. Just like vi.
Open a file. Insert some text. Use arrow keys to scroll. Hit Alt-/ to search forward. Hit Alt-Shift-/ to search backwards. Sure, some commands need you to switch modes, but not all.
> * It cannot take advantage of the modern computing environment -- mouse navigation, different fonts, text styling, page layout, or anything else. Just like vi.
One can do text styling (but only with colours, I think) with vim. With gvim, one can use a mouse, and change fonts.
Your claim is that what I said is false.
> Sure, some commands need you to switch modes, but not all.
Your claim is that what I said is true.
Only one of the above comments can be so. If one is true, then the other is false. Take your pick.
That's for sure. In a single post he asserted both that there are modes, and there aren't modes. That leaves no room for another viewpoint.
There's one sure way to win an argument -- assert all possible viewpoints, declare victory, and depart the field.
Far from "[asserting] all possible viewpoints", I mentioned specific keystrokes that you could try out too. If you are in insert-mode, and use arrow keys to visit a different location, you'd continue to be in insert-mode. Is it implemented as a secret hack to quietly enter and exit the scroll mode when arrow keys are pressed? I neither know nor care. However, in this usage scenario, modes are not exposed to the end-user.
* actually, I do like modal behaviour, but in very few cases. In MS Windows, it used to be the case that Win-space z would put the window in resize-mode. One could then use arrow keys to resize the window. There was a similar sequence for moving windows too.
I was under the impression, vim does have clipboard support. Putting "set clipboard=unnamed" in ~/.vimrc integrates it with system clipboard (at least on OSX).
I was wrong about that. As it turns out, in some environments, by reconfiguration you can make vi/vim recognize the system clipboard, even though it's terribly unhappy about it, and even though the change isn't transferable to all working environments.
I stand corrected.
I find it a plus that I'm not having to move my mouse hand off the base row all the time, and find that vi offers elegant solutions to many oft-recurring tasks people normally accomplish with a mouse (copying a row or two, highlighting text inside brackets / inverted commas, editing a variable name up to a specific point, etc). While I agree that the incantations required are relatively complex, they do become second nature (e.g. I'm an on-and-off user of perhaps 2 years, and I'm comfortable with the basics). This of course comes at the cost of having to switch modes often (and specifically, exit current mode using ESC, which is irritating), but this normally only involves 1 key. I guess a complete cost-benefit analysis would be highly subjective, in my personal experience the trade-off is worthwhile. In short, I'm not aware of anything that comes close to the terseness of vi(m) for basic editing.
> The bitterness seething out of your every pore that your software has been consigned to the graveyard ...
Dream on, moron. Apple Writer belongs in a museum along with vi. What's astonishing is that people are still using vi when there are any number of much better choices.
> ... whilst Vim is growing in popularity is so tangible!
Based on that fantasy, you may want to resume your medication.
Yes, and vim = vi with decorations, but essentially the same editor. Or did you miss the first time I pointed that out?
It's been 5 months since I switched to Emacs. My .emacs.d is actually bigger than .vim_runtime was, but it's because of more configurable features found in Emacs plugins, so it's natural. My init.el is also longer than my .vimrc, but this is because of much friendlier Emacs API and my love for Lisps (and dislike for vimscript). On the whole I'm quite pleased with the switch, although making Emacs into my editor took a comparable amount of time and code to Vim. I don't use Evil or anything like it, of course.
Emacs is better in many respects. CEDET is nice, SpeedBar and imenu with it's syntactic extensions work wonders - TagBar in Vim comes close to SpeedBar, but there's no imenu. auto-complete is better than omni-complete and easier to extend. Eshell works better than conque. Icicles, ido and smex make working with minibuffer a pleasure to the extent that Vim could never match - although it has basic completion of commands. Of course there is more, but the important thing to note here is that, while Emacs implements many things a bit better, Vim has them too. And it's perfectly reasonable to prefer Vim versions. So what I'm saying is that I found Emacs better but Vim is still really great.
Ok, so now to the modality. Emacs lacks modes, Vim has them. Last time we talked you were saying that modes are inefficient and hard to use. I could argue for modality then, but not against it, because I lacked experience with non-modal editor. Now I can compare the two.
The truth is that I was suspicious of non-modal editing in Emacs. I heard and read many rants about long sequences of modifier keys you need to press in order to do something. Turns out these rants where right for the most part. Some examples: C-- C-4 C-x <tab> performs hard dedent by four spaces. C-s C-w C-s ... performs incremental search (forward) for current word (Esc # in Vim). C-4 M-f goes four words forward (4w in Vim). There are also tricky ones, like C-x d opening dired and much easier to type C-x C-d displaying a list of files in current directory in a buffer.
In practice, however, with some amount of remapping, this is not an issue. But wait, isn't pressing escape instead of some universal prefix (C-c for user commands in emacs) not a problem in practice, too? After using Emacs and Vim I can say that the complexity of commands in both is almost the same. In Vim I remapped Esc to CapsLock - in Emacs I have Ctrl in place of CapsLock (although I'm contemplating placing Alt there and Ctrl in place of Alt). The only real difference I feel is that in Vim I could just hit the first modifier key (esc) while in Emacs I need to keep it pressed. Emacs uses Alt (Meta), while Vim does not, but that's a little difference, because Alt is usually in a place that's easy to reach.
In conclusion, while I like Emacs very much, I still find your claim that "modal editors" are for sad, handicapped individuals who just don't know any better full of bullshit. Modality is not any worse than modeless model in itself and Vim implements modality in a way which makes using it as convenient as Emacs chords. While there are other things I like in Emacs better, bashing Vim because of modes alone is pure stupidity; bashing it because of it's ancestry is an equivalent of saying that "your mama is fat" and saying it has no X feature is most likely false anyway.
PS. Elsewhere in this thread you're saying that Vim can't use mouse and clipboard. Of course it can - <esc>"=y copies to system clipboard instead of local one. I admit that Emacs support for mouse events is by far superior, and of course typesetting - colors, sizes and styles of fonts - are well supported in Emacs and not in Vim. But reaching for the mouse is bad anyway and if you have to, Vim supports all three mouse keys, which only makes the latter a valid claim. It's up to everyone to decide whether they truly need different fonts in their editor.
While I respect the research done concerning modal UI and the associated consequences of that in the context of HCI, in practice I do not find that there is ever any confusion about what mode I am in when using Vim after using the editor for many hours, and if one was supremely concerned with avoiding such confusion UI changes per state could be implemented so that the changes were unavoidably obvious (such as by changing the entire background to a different color on a context switch).
The design has some nice benefits elsewhere too with how Vim uses it.
However, I do not find Emacs chording emphasis particularly demented either though, especially once the full array of modifiers are used.
The amount of chords is only really burdensome due to how many domains Emacs covers though IMO, as it makes collisions with short chords much more frequent as the amount of keybinds necessarily expands.
I find the criticisms of Vim usually extremely exaggerated and generally indicative of ignorance concerning its design, some of which you have correctly noted and addressed in your response.
That is not to say that Vim is without its imperfections, but the design is well thought out, coherent, and well documented which makes the learning curve bearable.
I find a mixture of chords and modes in Emacs quite nice using Evil-mode as I can choose to either avoid changing states or not, unlike in Vim.
As I have noted elsewhere though, there is no intrinsic reason why Emacs must use chording over a modal design or some other means of using individual key sequences to invoke commands.
It is merely a matter of redesigning how commands are invoked across Emacs, something which some people are working on and may be interesting in the future.
I do wish there was something up to date that was similar to Practical Vim but for Emacs though as that was a very illuminating and fun text.
Do you know of some documentation that elucidates CEDET more than the documentation on the site does? I have read that documentation a few times and have yet to grok what it really does and how one would use it in practice. It seems extremely powerful but I do not see how an end user takes advantage of it or how an extension writer would use it to compose an IDE for a new language.
1. Thanks for correcting me.
2. Four characters. Very efficient.
3. All to avoid using any control keys. The reason? vi must be able to work with a keyboard that doesn't have any control keys, and vim must work exactly like vi.
Not only do modern keyboards have control keys, but modern computers have mice and other pointing schemes. But vi/vim lives in a permanent time warp, a warp so profound that an old, justly retired editor I wrote in 1977 was far better at exploiting technological advances.
Why was Apple Writer retired? Its limitations quickly became obvious, especially once early Apple computers supported mice (which happened before the Macintosh). No one wanted to keep using such a dinosaur in modern times, including me.
About keyboard, mouse and clipboard support:
> Not only do modern keyboards have control keys, but modern computers have mice and other pointing schemes.
> All to avoid using any control keys. The reason? vi must be able to work with a keyboard that doesn't have any control keys, and vim must work exactly like vi.
> * It cannot take advantage of the modern computing environment -- mouse navigation, different fonts, text styling, page layout, or anything else. Just like vi.
> Keyboards have changed, but vi hasn't. Computers have mice and touch-sensitive displays, but vi can't exploit them. Operating systems have clipboards, but vi can't take advantage of that convention. You know -- don't get me started.
> * No clipboard support -- all copying and pasting operations, apart from being another example of bizarre vi incantations requiring the recall of a raft of magic characters, is within vi/vim and disregards the system clipboard.
> What you see as vim appearing to exploit a mouse and system clipboard is actually Bash and (sometimes) a command-line app (example Konsole) doing so, or equivalent utilities outside vim in a non-GUI level. Those features work with any editor in exactly the same way.
> As to using the system clipboard just fine, you can copy text from vim or any other displayed source of text, but you cannot paste it, because it's not vim that's acting, or is in any way aware that text has been copied.
That's what you wrote. It's all false. First, let's level the playing ground - we're now talking about GVIM, which comes with every Vim installation (unless NO_X11 or something is defined at compile time). Whenever you see the word "Vim" below it means GVIM. To make sure we're really talking about the same thing, here are some screenshots of GVIM in action:
http://screenshots.en.sftcdn.net/en/scrn/92000/92299/gvim-7.... http://www.kianryan.co.uk/wp-content/uploads/2012/09/Screens... http://labnotesh.files.wordpress.com/2008/12/gvim-windows.pn...
This way we can avoid going into terminal emulator and consoles details, and focus on Vim itself rather than on things it can be accessed through.
Ok, so first the keyboard and modifiers keys. It has been told you many times already that Vim supports those. It should be evident from the fact that Vim manual describes default keybindings with modifiers in them. For the example look here: http://vimdoc.sourceforge.net/htmldoc/windows.html#window-mo...
This makes your claim false - apparently Vim doesn't have to "avoid all control keys" (or "work exactly like Vi", but that's another matter).
Second, mouse. Of course it is supported, as explained here: http://vimdoc.sourceforge.net/htmldoc/usr_09.html#09.2 and here: http://vimdoc.sourceforge.net/htmldoc/gui.html#gui-mouse
It is even mentioned that the mouse works in console version, but let's leave it for other time and keep the argument simple. The point is that you can use the mouse for everything you would use it in other editors out of the box, and if not, then you can easily remap it to do something else.
Which makes you claim about Vim not supporting mouse obviously false.
The systems' clipboard support is of course available too. Actually, it is exposed by default via two special purpose registers, named 'star sign' (the thing that makes text italic here...) and '+', which is documented in http://vimdoc.sourceforge.net/htmldoc/gui_x11.html#x11-selec... Note that on Windows the latter is an alias for the former, because the system has only one clipboard. There are commands for placing text in registers, appending to registers and pasting from registers and they work in exactly the same way with 'native' registers and with the ones representing OS clipboard. So it's, of course, completely false that Vim doesn't support clipboard.
One thing of note, you wrote:
> Four characters. Very efficient.
in response to me pointing out how to get the text into clipboard. Well, it's because by default Vim doesn't use OS clipboard as a default register, but you can of course make it do so. If you really want.
On efficiency and modes:
> Some of them might even think it's natural to have to use twice as many keystrokes as are required on a modern editor, even another command-line editor, to switch from editing to navigating (as just one example)
> No, to switch from entering text, to deleting text, to searching for text, to copying and pasting text, to saving a file, to loading a file, all require switching modes. Let's be honest.
> Having to enter additional keystrokes, a throwback to a computer keyboard that either didn't have control keys or couldn't exploit them, makes editing "faster and more powerful"? Nice reasoning.
> * To perform multiple operations, like moving the cursor around, entering text, deleting text, searching the document, saving and loading files, requires you to switch modes. Just like vi.
> It is less efficient. But you are now obviously trolling, posing arguments that no rational person could possibly accept. "So, a few more keystrokes for each command, repeated for each such command. So what? Are you in a hurry to get somewhere? Do you want to live forever?"
Well, you basically say that having modes is less efficient than not having them. The problem here is that you don't present any evidence to back this claim. You say that you need to press more keys when working with Vim, but despite multiple people asking you to, you don't give even one realistic scenario where it would be less keystroke to perform an action in other editor. The few examples you provided were unnecessarily verbose and you were given shorter versions, which require at most the same number of keystrokes as other editors. And it's without custom mappings.
Despite this - and despite the fact that I even included <esc> for changing the mode and still got shorter commands - you're convinced that having modes necessitates more keystrokes to perform an action. I'm at a loss here, how could I ever convince you otherwise? You didn't even post any more examples of what you think takes more time in Vim as if you thought that the previous ones are enough to prove your claim. It's silly - and false. Of course.
The truth is that having modes allows for not using modifier keys, except for one. Without modes you need to use them, because you have no other way of differentiating text input and commands. And that's all modality does, by itself - replaces a few modifier keys with a single one. It has no impact on average count of keystrokes.
For example, copying a full line of text in other editors goes like this (well, using a mouse is an option, but until it's proved or disproved to be fatser than keyboard for text editing I'm not going to include it):
Home, Shift+End, Ctrl+C
In Vim, thanks to modality, the command doesn't involve modifier keys and is equally long (or if you count pressing modifiers as keystrokes - shorter):
<esc>yy
For replacing text inside parens, starting from inside:
go to one of the parens, Shift+Alt+arrow, arrow in opposite direction (to deselect matching paren), and start writing (inserting deleted paren)
In Vim:
<esc>ci(
Moving a paragraph below another one:
go to the beginning of the paragraph, press shift+arrow down enough times, ctrl+x, move to the end of next paragraph, ctrl+v
(No wonder using mouse is more efficient than this!)
In Vim:
<esc>dip}p
And so on. Of course, you can shorten the modeless commands by introducing additional, special purpose commands, so don't take them seriously, but that's not the point - do you really think you can shorten them any more than what Vim does? If so, please show us. No mouse please.
Anyway, if keystrokes count remains the same, why bother with modality? I don't know, to be honest. Vim proponents claim that (with <esc> mapped to CapsLock key) they never leave home row. I'm not a touch-typist and so I don't feel it's a great difference. But at the same time I can't see why is it a bad thing. The keystrokes count stays the same. Chaining is easier, especially when using numerical prefixes. There is a bit of an overhead in that you need to learn of various commands for changing modes - and everyone using Vim admits this - but that does not hamper efficiency in any way once learned.
I wanted to, but I think I won't comment on the rest of what you wrote, because it carries no substance whatsoever. We're really not interested in ed, ex and vi early history, we're talking about current versions of Vim, which is, contrary to what you say, != vi. So here you go, your claims at least commented at length. I hope it's enough and that I will be able to just paste the link to this post under your Vim related comments in the future.
It's too bad you're unable to find any examples to support this claim. On that topic, here's just one of your outright lies:
[ my remark ]
>> All to avoid using any control keys. The reason? vi must be able to work with a keyboard that doesn't have any control keys, and vim must work exactly like vi.
[ your reply ]
> That's what you wrote. It's all false.
As a matter of fact, more key entries are always required in vi and vim compared to a modern editor, and two, the control scheme in vi and vim arises from the requirement that it avoid the use of control keys. That was a design requirement, because the original machines it was designed for did not have control or navigation keys. How do I know this? I used those computers, and I used the early versions of the programs under discussion.
Since then, the machines have changed, but vi and vim have not changed.
Stop lying.
> I wanted to, but I think I won't comment on the rest of what you wrote, because it carries no substance whatsoever.
I already used repeated and substantial evidence to prove that that you are lying, and you just lied again.
> And that's all modality does, by itself - replaces a few modifier keys with a single one. It has no impact on average count of keystrokes.
I and others have already proved that this lie is, in point of fact, a lie. Mode-limited editors require more keystrokes than those without modes. Mode-limited editors require you to be aware of, and to change, modes. Those mode changes require extra keystrokes.
* Vi/vim, switch from moving the cursor to editing text: Esc, Esc, :, i, fist text entry. Four additional keystrokes. Newer versions have s shortcut in which you can just press i, to switch modes, one additional keystroke. But all version of vi and vim always require additional keystrokes, compared to a modern editor.
* Modern editor, switch from moving the cursor to entering text: Just start entering text, no additional keystrokes required.
You are lying.
> We're really not interested in ed, ex and vi early history
First, based on the positive votes on my posts, there is no "we" that lacks interest, and second, one of the the reasons your post is so misguided is because you don't know anything about the history you feign disinterest in. The other reason is that, like a religious True Believer, you cannot be persuaded to argue in good faith.
> Anyway, if keystrokes count remains the same, why bother with modality?
One, I just proved that keystroke count doesn't remain the same, and two, the reason for modes is to avoid use of control keys, for the reason that those keys didn't exist on the keyboards for which vi and vim were designed.
The designers of vi and vim had no choices about modes, it resulted from a limitation of 1970-era computers and terminals, and such modes have been abandoned by all modern editors without exception, as a clear hindrance to efficient use of a computer.
Stop lying.
The original docs for vi, written by Bill Joy and Mark Horton, are online. You can see quite a few places where the docs explicitly refer to control key combinations. For example:
http://docs.freebsd.org/44doc/usd/12.vi/paper-8.html#section...
vi was developed in 1976 on the ADM-3A dumb video terminal, and that terminal had a ctrl key. I remember because I had one. You can see the ADM-3A keyboard here:
http://www.catonmat.net/blog/why-vim-uses-hjkl-as-arrow-keys...
The author of that page also explains why Bill Joy chose hjkl as movement keys. Note that those keys have arrows printed on them to indicate that they move the cursor when used with the ctrl key.
Although vi was never intended to work on paper terminals as you claim (having the line-oriented ed embedded as a mode does not make vi equivalent to or derived from ed), the most common paper-oriented terminal in use back then was the Teletype Model 33, and it had a control key. You can clearly see it here:
http://www.baudot.net/gil/tty-machines/pics/M33-ASR-Gil-Keyb...
The ADM-3A gave way to video terminals from DEC, HP, Wyse, Hazeltine, etc., and they all had control keys. I've worked on a lot of terminals in my time, and I have to go back to keypunch machines to find something that didn't have (or need) a control key.
So what machine did you use vi on that didn't have any control keys?
If such a terminal indeed existed and you were forced to use it at NASA, I'm sorry. The experience obviously left you bitter and scarred. But please stop making claims about vi and early terminals that are simply and obviously false.
I don't know if Bill Joy modded his ADM-3A, but for anyone who wonders why vi uses esc instead of caps lock to switch modes it's because there was no caps lock key back then. I believe Bill Joy and the vi cartel deliberately suppressed the caps lock feature on early terminals to make vi users miserable in the future.
---
lutusp 2 minutes ago | link
> You repeatedly claim that vi is lame because it has to work with keyboards with no control keys. What? "vi is lame because it has to work with keyboards with no control keys"? I never said that anywhere. You will now try to find your source for this lie, then you will apologize for lying. For God's sake -- how can you people expect to have useful conversations while making stuff up? If you had said, "I think I heard you say..." or something like that, I would cut you some slack for being stupid and irresponsible, but not under these circumstances. FIND THE QUOTE. THEN, REALIZING THAT IT DOES NOT EXIST, APOLOGIZE. I won't hold my breath for you to accept adult responsibilities.
---
OK, I'll take the troll bait. You wrote: "I never said that [vi is lame because it has to work with keyboards with no control keys] anywhere. You will now try to find your source for this lie, then you will apologize for lying."
I'm not going to apologize to you for anything, and you show yourself to be quite a jerk telling me that I will apologize for pointing out your factual errors. You don't even bother to address the facts I posted. But showing you where you wrote what you claim you never wrote is easy. You can find all of these quotes in your own comments:
* "The reason? vi must be able to work with a keyboard that doesn't have any control keys..."
* "... the control scheme in vi and vim arises from the requirement that it avoid the use of control keys. That was a design requirement, because the original machines it was designed for did not have control or navigation keys. How do I know this? I used those computers, and I used the early versions of the programs under discussion."
* "And do you know why this arrangement exists? Because there were teletype terminals and early glass terminals that didn't have control keys. No control keys, no way to exploit their existence."
* "I wrote an incremental improvement over vi, one that exploited the existence of control keys..." [Implying that vi did not or could not use the control keys, which didn't exist back then anyway according to you.]
* "It's false when comparing mouse use against a modern keyboard with control and function keys, and it is certainly false for the limited keyboards for which vi/vim was designed, those keyboards that result in vi/vim not being able to exploit control characters."
* "Having to enter additional keystrokes, a throwback to a computer keyboard that either didn't have control keys or couldn't exploit them, makes editing 'faster and more powerful'? Nice reasoning."
* "Vim still imitates vi, and vi still imitates 1970. Extremely inefficient, steep learning curve in order not to press readily available control keys."
* "As soon as someone invented the control key and its purpose, and well before Douglas Engelbart invented the mouse, the retirement clock started ticking for vi and vim." [I guess not since vim is installed on all Unix and Linux distros and comes with OSX].
I provided links showing the ADM-3A and Teletype Model 33 keyboard layouts -- both with control keys. And that was the standard keyboard layout back then. Show me a terminal that was in widespread use when vi came out in 1976 that didn't have a control key. Not that it really matters if you find some weird example, because vi was specifically designed for the ADM-3A and similar terminals available in 1976 that had control keys. That's from Bill Joy.
Your repeated claims that vi was designed for paper terminals, or that vi is derived from ed (rather than the reality that vi incorporated ed) are contradicted by knowledge of vi but also by the authors of vi. You wrote:
* "vi, which had to be able operate with a 'paper terminal', essentially a roll of paper as a display..."
* "I can say this in vi/vim's favor: it's a step up from ed, its predecessor."
Both obviously false.
Read much? You claimed that I said "vi is lame". In point of fact, I never said any such thing anywhere. Prove me wrong -- locate a quote that does not exist. You're inventing arguments to have with yourself.
I just went through your list of quotes, and everything in the list is true. "... there were teletype terminals and early glass terminals that didn't have control keys ..." Care to dispute this truth?
> I'm not going to apologize to you for anything ...
Of course not. You also won't avoid making things up as you have done in this and prior posts. Which leads an intelligent person to wonder what the point is of trying to discuss things with you.
You can dispute the presence or absence of control keys on early terminals, sure. But find one that was in widespread use after vi was released in 1976. I asked you already to show an example of a terminal that didn't have a control key that you used vi on. It's irrelevant, really, since vi was designed specifically for terminals like the ADM-3A that DID have a control key. Bill Joy's original vi docs support that statement.
The possible existence of some early terminal that lacks a control key doesn't change the fact that vi wasn't designed for such terminals, so it shouldn't be surprising that vi didn't work well on such things. Supposing they existed. I posted links and screen shots. What evidence do you have?
I haven't made anything up. I posted your own quotes verbatim and cited my sources for early terminals and the history of vi.
Give it a rest. No one is interested in this anymore and you are just making a fool out of yourself.
First, I never said either of those things anywhere. But, having sampled the level of personal responsibility among the people in this thread, I won't bother asking you to try to locate your source for those false claims.
The reason vi doesn't use control keys is because many keyboards in those days didn't have control keys to use. Which word don't you understand? The authors couldn't exploit keys that didn't exist, so they avoided use of an entire keyboard filled with control keys, an unfortunate necessity.
This is not to say there were no keyboards with control keys, only that the designers didn't want to lock out users having keyboards without control keys. That's why vi used letter keys for arrow keys, and shifted modes by means of something other than a control key, to make control functions possible in the absence of control keys.
> But please stop making claims about vi and early terminals that are simply and obviously false.
What? I should defend statements that I never made, that you invented and then tried to hold me responsible for? If you will stop inventing quotes, I will stop calling you out on them. Now, as just one example among many, locate where I said "vi is lame" ANYWHERE, FOR ANY REASON, IN ANY CONTEXT. And when you discover that you invented it, you will apologize.
I've given examples with supporting evidence. What evidence have you given to back up your claims?
I didn't invent any quotes. The quotes I posted -- using the widely-accepted quotation mark convention of English (assuming your keyboard has those!) -- are clearly indicated. The "vi is lame" statement is my own summary of your opinions expressed in this thread, it is not attributed to you as a quote but as a sentiment. Thus the lack of surrounding quotation marks.
But maybe let that bone go and try to produce any evidence supporting the meager meat of your arguments about early terminals and the history of vi.
I think most of us who learned vi back when it was simple have the keystrokes burned into our brains, and we know that vi is quite efficient once learned. I still use vim but not any plugins or extensions and I don't write scripts for it, because I just forget about them anyway and they aren't going to be installed on the GUI-less servers I ssh into. I use a more modern editor (TextMate) most of the time.
I don't think vi or vim are terrible, but they can feel clunky on modern GUI-based operating systems. A serious driver should know how to shift a manual transmission. A serious programmer or sys admin should know how to manipulate files and text with standard UNIX tools and editors. vi may not be the best text editor depending on how you measure "best," but it is ubiquitous and does the job it was intended for.
My advice for vim users is to start with the vanilla install, no plugins. Learn to configure things you really need in the .vimrc file. If you find yourself creating a complex and over-personalized editing environment to save the occasional keystroke or make vim work like an IDE, you are shooting yourself in the foot in the long run. You may as well just use Eclipse.
2) True
3) :set paste
4) Then wrap it in a function
5) I've always found ctrl-p to be snappy actually. You can replace the matcher with ag or similar
> write the Vim configuration lines required to cause those files to be ignored. You have got to be kidding me.
Write a small amount of config once per project? It's no more complex than adding things to a UI
set wildignore+=*/tmp/*,*.so,*.swp,*.zip
7) Stop just navigating with j and k.
> After reading this list, feel free to tell me how I'm doing it wrong on twitter.
You're not googling anything to find out the answer?
Also, because occasionally people haven't heard of it, get Gundo. http://sjl.bitbucket.org/gundo.vim/
Vim has a full tree undo, gundo makes it easy to navigate and see diffs between changes in code.
[1] cat .emacs.d/config/*.el | egrep -v '^$' | egrep -v '^;;' | wc -l
It takes time to be productive with Vim. There's no way to get around that.
It should be reasonably easy to create a function for this though, prefix each line in the buffer with 'indent(".")' spaces, or copy the whitespace at the beginning of the current line.
That pastes with adjust indentation.
I've been using vim for years and the only plugins I use are vim-airline[1] and vim-bufferline[2]. Of course, my editing needs may not be as complex as yours, but in reality most things you think you need a plugin for can be done with plain Vim. Feel free to check out my humble .vimrc[3] for some inspiration.
1: https://github.com/bling/vim-airline 2: https://github.com/bling/vim-bufferline 3: https://github.com/wolfcore/air-dotfiles/blob/master/.vimrc
That's it: you just need to give it more time. One simply can't expect to fully climb vim's learning curve in just a quarter of a year. Your brain can't adapt so rapidly to so much new shortcuts.
> Jump to CSS selector. Jump to class. Fuzzy string matching. All these things and more are what I am used to. Vim just can't do them.
That's one example among others: there's vim's marking system for that, and your brain isn't just used to it now. You find it slow, broken and not user-friendly, but it's not really, it's just that you need to give it time to master it.
My 2c advice: it you really want to like it, keep going and give it a full year. If you think you can't give it more time, then Vim isn't for you and some commercial editors might do it.
I've been there, I know your current feeling. I'm a happy vimmer now but it hasn't been the case for something like a year. There's a reward for real vimmers: you'll never need to switch anymore to another editor, because Vim is there, powerfull, opensource, free, multi-plateform, and you know how to use it smoothly.
I'm really curious; missing this feature from heavyweight IDEs.
"Jumping to somewhere in an unbuffered file according to where I am in the current buffer", that is actually depending on a background worker that knows a very specific set of rules and use it to constantly cycle threw the filesystem. Which bg process is usually provided by tanks like Eclipse.
With the time I've found something that matches that behavior without the payload on the computer, and guess what, it's my brain.
I'm no more in pain of jumping to the definition of a css rule, because I know which css file I have to invoke and I can do it _very_ quickly thanks to Control+P, and jumping to the definition is a matter of one or two "/".
Of course you need to organize things smartly in your project if you ever want to do that without too much thinking time, but hell, I count that on the bright side of this solution.
It would drive me _crazy_ if vim saved without me telling it to.
I think a lot of people suffer needlessly trying to make vim be what they want it to be, when it never is going to meet their expectations. You'd be better off trying to get those things you find useful about vim implemented in TextMate or Sublime than the reverse.
It's horrible because you're not quite sure sometimes if there was a legitimate change made in another process that you're now about to undo. Half the time I end up copying the lines I know I added, allowing a reload, and then pasting them back in, just to be safe.
Personally (regarding the original gripe in the post) I'd be horrified if my text editor was silently ignoring edits or just updating the code under me. If that was really a concern while I was working on my software I'd take a look at the workflow to see what could be done about it.
Your configuration is always evolving - so don't fret if a plugin or a setting is not working for you, it just means its gotto go..
That said focus on `your productivity` over a religious choice of an editor. You actually got to live with it for decades to come. choose the right one which fits your use case.
On 5, ctl-p works great for me. I have it set up to use git in choosing what to ignore and it's plenty fast. On 6, I probably just don't know any better.
Answer to some of the points,
Janus: There are divided opinions in vim community about whether distributions should be used or not. I am on the latter side. But still for just checking out I installed Janus a while ago. Yes it is slow, but it turns out that it is as slow as my then `.vimrc` configuration. I tried to track down the problem. It is because of vim's blocking behaviour during executing external commands. When you write a buffer or switch to a buffer, syntastic, tagbar, powerline statusline, gitgutter, bufexplorer all execute external command. Vim becomes more slow when `.git` repository grow larger or when saving a large file. So how do you solve the problem? Remove those plugins and install Unite.vim[1] with vimproc[2] asynchronous library.
Files that change: If you do external edits more frequently then I think it is time to rethink your work-flow. I think there is a common consensus that you should not run live edit in server.
* Indenting pastes* : There is a plugin for that [3] ?
* Opening files inside my project : Last I checked command-t was damn fast, don't know where slowness comes form. Another alternative is `Unite.vim` `file/async` source. It is fast at finding files but goes slow while doing ignore-pattern checking. Without the checking it is DAMN FAST. The `phpcomplete/files` source I created for my php autocomplete plugin[4] easily list 4000+ files in seconds. If you want to list files obeying the patterns in the '.gitignore' or '.hgignore' files. Checkout my unite-file-vcs[4] plugin. It adds a `file/vcs` source that lists files by issuing `git ls-files` or `hg status -c -m -u` command for `git` or `mercurial` projects respectively.
Navigating inside files*: Checkout unite-outline[6]. It shows live output by parsing the current buffer. Unite.vim required. But it does not support css files right now. Adding support should be easy.
So the summary of the story. Move to `unite.vim` and friends ;)
[1] https://github.com/Shougo/unite.vim/
[2] https://github.com/Shougo/vimproc.vim
[3] https://github.com/sickill/vim-pasta
[4] https://github.com/m2mdas/phpcomplete-extended
It's possible this isn't what you meant, but external edits do not imply editing code live on a server.