I think the idea with vim is that if you've been using it for years and flying back and forth between modes is as easy as breathing, it can allow you to do a lot of cool stuff that you'd otherwise have to do manually. It's just that the learning curve is a stone bitch and you don't see any immediate benefit as you're slowly learning to fight your way through the interface.
Just don't ask me what the benefit is of being able to, say, reverse the word order of every two-word line in a file. I'm not a vim user, just the daughter of one.
admittedly I am a vim user. it is definitely not an intuitive editor. I've been using vim for ~6 years, and I still learn new stuff every couple of weeks. but I am much, much faster using vim than anything else I've tried for code editing. that speed up has come in bursts over the years.
some of your complaints can probably be fixed by altering your vim configuration. like having left-arrow go to the end of previous line in insert mode.
vim doesn't purport to be good at general text editing (to my knowledge), just code editing. it'll do plenty of auto formatting for you (like notice that the previous line was indented and the next one should be as well) but it does all of this based on what language it thinks you're writing (based on file type) and a configuration file that tells it about the syntax of that language.
it's not just *a* clipboard that it keeps outside of the system clipboard. vim has lots and lots of buffers, copy/paste just happens by default from one of them.
I look forward to hearing your first impressions of emacs. I don't want to taint your results, but it's basically a terrible operating system that someone decided they could use as a text editor.
You don't see anything wrong with "reviewing" something before reading any of the documentation?
vim is one of the most extensively documented apps out there and your comments don't indicate much except that you are unaware of how to use it.
As a starting point do :help vimtutor
I use vim, and an acquaintance pointed me to your blog, and I think I need to comment.
Surely you're aware of the historical reasons the command structure/mode is the way it is, yes? Vi, the vim predecessor, predates mice and other pointing devices, and even predates graphical interfaces. It's designed for efficiency - the kind that comes with practice.
Just as anyone can use a graphical text processor, and it takes effort to learn vim (with much frustration and falls along the way) and be fast and proficient -- so also anyone can use a tricycle, and it takes effort to learn a two-wheeled bike (with much frustration and falls along the way) and be fast and proficient..... Or is it the other way around?
It's designed to be a powerful text editor -- meaning to edit/change/modify, not a text developer.
It's a tool that is exceptionally good and efficient at what it does. I think you may be reviewing it with the thought that it is designed for a different use than you expect.
Happy text editing!
Hurray for acquaintances!
The weird thing is, I can't put your three different perspectives together at all in my head. I keep trying to extend your arguments into a synthesis, and bizarre things pop out in my head:
"You need to cut the bicycle some slack. It was developed before the time when third wheels existed. We may have better solutions for handling balance today, but we shouldn't judge the bicycle for its failure to stay with the times."
"What, you just expected to jump on a bicycle in the Hague and ride it to your classes in Delft? No wonder you were unsatisfied -- that's not what it was designed for! It was designed to ride down the block to your friend's house, and to otherwise move around in short paths. Of course it seems like quite a waste compared to the trike for going long distances infrequently!"
"Back in the olden days, we didn't really have to write code, we just had to edit short snippets of it. Back then, our programs were basically entirely written for us, and writing whole new programs was unheard of."
Needless to say, none of these really resonates in my head. They all sound bizarre and fundamentally wrong to me. Some parts of it become more synthesizable if we talk about fixed-gear bikes
versus gear-shifting bikes, as fixed-gear bikes do indeed predate derailleurs, and lack modern bicycle conveniences like, well, gear-shifting. And coasting. Still, you don't need to consult a manual to find out how to start and/or stop a fixed-gear bike; you just feel uncomfortable on it when you're going over a bump and the bike forces you to keep pedaling.
In any case, the reason why I was writing code with it was because I was told that it was good for writing code -- that it would make me far more productive of a code author in the long run. I've since been told by people such as yourself that no, this was in fact wrong -- vim apparently stinks for code authoring, but is great for code editing
. That just seems like a stretch to me.
(Probably the most useful comment was that someone on IRC told me how to get vim to auto-indent like a proper text editor. I don't know why this isn't in the default vim implementations yet.)
First of all. Unless you're only writing view templates the vast majority of any developers time is spent editing code, not writing it.
How often do you create a new object versus editing an old one? Exactly.
Second. RTFM. Multiple generations of developers have found learning vim to be a rewarding activity but not a single one of them has said it was easy. If you're not willing to read the manual fine then, don't use it. But don't then whine about how it doesn't do this or that (when it does).
I've read literally hundreds of articles and tutorials on vim but this is probably one of my favourites for just giving a taste of why us who know it love it.
Oh and also very useful for those just getting started with vim (actually I still refer to it myself for obscure stuff).
Starting to understand why everything is a one letter command? The aim is to never have your hands leave the keyboard and to do as much with as few keystrokes as possible.
In turn, my time is mostly spent on either authoring new code or figuring out where I've written some false assumption into my code. Editing a line of code has never been a painstaking task for me. I have literally *never* even remotely gone, "oh, it's so hard to get to the center of this line and edit the number '2' to the number '4' -- oh life is so tough, oh how will I go on?" Compare this to the frustration I regularly endure when debugging. (For example, in that same Updater() code, it took a long time to find out that I was assuming that the "this" keyword would be a part of a function's closure when it was passed into the window.setTimeout() function, when in fact the "this" keyword works a completely different way than a local variable in that regard. You really should have heard some of the swears coming out of my mouth when I was debugging this particular snippet.)
Of *course* I ended up reading the manual. vim doesn't give you a choice on that matter. You have to google up manuals and tutorials and RTFM before you start using it.
(It's not obvious to me why there should be manuals at all for text editors, though. Let me give you an example: My freshman programming course was taught in Java, and used an IDE called DrJava, which I haven't really used since because, well, I don't really like Java all that much. I didn't require *any* manual to just start using DrJava. The features that it added to my Java programming experience were not only easy-to-understand -- "Oh, this is labeled as a Java Console, presumably, I can type Java code into it and see what it does" -- but it was also obvious that its use would cut down on my code development time -- "Oh, you mean I don't need to point my main method at my latest test method, jump to another console, recompile the program, execute the program, and then try to remember what output I was expecting? Sweet." Same thing when I first got a Linux server: someone mentioned to "nano" this or that configuration file to me, and I immediately grokked how nano works. The fact that a manual should be necessary to learn an editor -- whether a sophisticated IDE or a cheap text editor -- is therefore not obvious to me in the slightest. I've picked up IDEs in the past without manuals. But in this case, yes, I was forced to read manuals and tutorials in order to find out basic questions like, "how do I actually go about *editing text*?" )
And I didn't realise how much I hated CRT screens until I started using LCD. :-)
I can say little more than thousands of developers, some of whom are undoubtedly more proficient than you, have found getting to know their editor to be a worthwhile chore. Assuming you know better without actually giving it a go seems a little off base.