But I have to wonder: is this the best that Vim can do? Vim as a language is a great concept. But IMHO, the execution sort of sucks. Twenty years have gone by, and 'Vim as a language' is still a big mystery that takes a long long time to understand...
Someone should take that concept and run with it. Surely 'editor as a language' can be done better.
For example if you press v and then repeat l until you're at the end of the word, and then do something with the selection, vim (or a plugin maybe) could tell you 'hey, you could have done that with ve (e moves to the end of the current word)'.
(Of course, Vim does have text objects, which are fantastic - one of the chief reasons I use Vim. But they have limitations; I think you can go a lot further.)
Or if you have days to burn, emacs+paredit+evil can russtle quite a few jimmies if you take the time to define some custom keybindings for it.
Paredit would be a step in that direction: http://emacsrocks.com/e14.html
I also recall editors of old having that functionality (Zmacs?).
EDIT: fixed url as per @nocman's advice.
Believe it or not, Emacs is quite a fluent speaker. I was surprised to find that even esoteric things like rectangle selections work perfectly and :%s incrementally showing the results of your search and replace as you type is a hoot.
Sure, emacs has its own accent and quirks, but after using emacs+evil as my only text editor for the last year, I'm now convinced that emacs is a better "vim" than vim itself is.
I could go on and on about how using evil+emacs brings vim keybindings to my editor, mail client, music player, IM client, etc which vim could never provide. I could talk about how wonderfully extensible elisp is for hacking up Emacs' core internals. But at the end of the day, I only use emacs+evil because it's an environment that I'm comfortable with.
If you have a few days/months/years to lose yourself down this rabbit hole, why not give it a try?
The way emacs handles indentation is already a huge improvement.
Understanding Vim's nOm command pattern is pretty easy (repeat n times operator O to text motion command m moves over). But using it effectively takes some practice. Committing it to muscle memory takes about 6 months (same amount of time it takes to master touch typing). You cannot do this faster.
Becoming an expert (which means not only effectively choosing and using commands to transform some text, but knowing a decent subset of entire functionality and also knowing how to extend the functionality) takes even more time.
And if your language were that primitive that mastering it can be done in a day or two, would it really be that complete and high level enough?
Granted, emacs keybindings deliberately don't constitute a language (the whole point of emacs is to remap them for different functionality in different contexts), but I don't think it took me much longer to "become an expert" at vim's language of editing.
Also, this thread's article doesn't go into keys like ftFT;,#* or the incredibly useful Vim-specific feature called text objects. This gives a good introduction to a lot of that: http://www.viemu.com/a-why-vi-vim.html
Also, I like to think that Vim is not an editor. It's a language or, you may even say, a concept of editing text.
The fact that die hard vim users are amazed whenever they learn a new trick they never encountered in ten years of using vim every day speaks for itself. (And happy mouse users look at the obscure shortcut for incrementing an integer and shrug.)
OK — mod me down into oblivion.
Other times, what you need, is to append a certain string to every line in the text containing a certain regular expression. Other times, you need to delete a column of characters and move that column somewhere else.
Vim (and emacs) is not about the most common keystrokes. It's about every other obscure and relatively rare task that comes up, that in total, add up to become a huge chunk of the working programmer's time. Yes, adding characters to the beginning, middle, or end of a line is easy without vim. Yes, moving up and down paragraphs or around the file can be done without vim. The power of vim is not manifest in these simple maneuvers, but in its expressiveness in handling every other exceptional case.
What I like is watching the vim or emacs advocate show me their macro examples and then showing them how BBedit (for example) leverages regexp (and provides lots of learnable shortcuts, macros, and scripting support) while getting you enormous benefits out of the box because it uses a mouse.
If you asked me to show you why I find value in editors like vim and emacs, I'd show you a DSL I wrote for work purposes and show you the extensions I wrote to edit them efficiently. Alternatively, I'd show you a number of customized workflows for cross compiling lua to C# or something.
I've used sublime text, textmate, bbedit and I'm not saying they aren't well designed editors. They are and if the stuff you are doing is stuff that everybody is doing, then great. But I don't think you understand that at this point in time, none of these GUI-based editors come even close to satisfying my personal needs as a developer.
Of all the communities online, let's have faith that at least on HN a well-argued comment will receive recognition whether or not it reflects a popular opinion. To bait downvoters is to imply that this community prizes popularity over integrity, and in doing so polarizes the discussion.
No. The vim language has a simple and easy to understand grammar that is very close to that found in many natural languages. That part is freaking easy to grasp. The vocabulary is a lot bigger, though, but like with natural languages, you can be a perfectly functional speaker/user without knowing everything there is to know. As long as you make yourself understandable and know how to use a dictionary you are fine.
And, like with all natural languages, practicing, making mistakes… are keys.
>Surely 'editor as a language' can be done better.
everything can always be done better, but its a matter of doing. When the doing starts, it will appear that its not as easy in execution as conception.
Even if you are using vanilla vim you can learn the basics of how to edit a file to notepad levels in about 1 min. (command line vim "new file name", press i, use as a normal editor, press escape, press :wq)
Nobody said it'd be easy
There are many problems that started out as pains but are second nature to us now, so we don't think to optimize them.
I remember spending a ridiculous amount of time trying to figure out link and include paths to add a new library in visual studio when I was a new programmer. Doing so now is so easy I hardly need to think about it, but in reality it hasn't gotten any easier. I am simply familiar with the process.
Really, installing a new library should be as straightforward as installing an extension in a web browser. There is little essential complexity there, and yet this process has not become easier (in C/C++) for decades.
Anyone who knows enough about how to solve the problem has already groked it and isn't interested in solving it anymore. This is the problem I see with wanting an improved vim from someone who is already a vim expert. The problems they have with vim are disjoint from the problems a new programmer would have with vim.
What I will say is that if you are going to create a new editor, by the time you are done you should have become an expert in all the major text editors. You're absolutely right that any new editor should have seriously considered the features available in vim and emacs and others. However I have no problem with someone who isn't an expert getting inspiration to create their own editor out of their frustrations with vim. Many great things were stared in similar ways by people who weren't experts (yet).