> Now vimscript doesn't do threading or evented io or thousands of other things - it isn't meant to do any of those.

Neither does Emacs Lisp. But whilst Emacs Lisp started as a simplification of a battle-tested general-purpose language, Vim Script started as a hack and continued that way, with further functions being added on a "as-needed" basis.

> As far as quirks go, all languages have quirks. PHP and JS probably have more quirks than Vimscript.

Effective analogy. PHP and Javascript started as hacks as well, they weren't meant to do much at first, and shared the same fate of Vim Script. The reason people put up with PHP and Javascript is that they had or have no alternative. And if there were no modal editor other than Vim, I myself would put up with Vim Script as well.

> Since you are so critical of Vimscript, care to cite me the pain-points which stop you from writing decent extensions in vimscript? There are a variety of scenarios in which vimscript implementation is much more simpler to an elisp implementation.

This is what we could name a "Perl fallacy": Perl scripts can be much shorter than scripts in other languages, but the former are more of a PITA to write.

However, I can cite a pain point: I can't write stand-alone applications with Vim Script. You may say this does not matter, because we are talking about extension languages here, but my view is different (and this was one of the original objections of mine). Why learn shell scripting (or something similar), different command-line text processing tools with their quirks when you can learn one framework well and use it for everything?

Evidence shows that Emacs' packages can go beyond Vim's, even when we factor out the kitchen-sink approach of Emacs. For instance, whilst Emacs programming packages parse - thus understand - code while perform syntax-highlighting, Vim's packages rely on regexps, thus messing syntax-highlighting when the syntax of a language is not quirky.

I don't understand your grep example, but providing an Emacs Lisp implementation would be pointless anyway. Languages are not to be judged so much by the terseness of their programs in specific cases as by their consistency and easiness of reading in general cases. Vim Script code is difficult to read because uses keyboard macros heavily, and suffers from accumulated cruft, where equivalent Emacs code would use named procedures with meaningful and consisten names.

> I find recording macros in vim simpler than emacs.

By "macro" I meant procedures, not keyboard macros.

> It mostly boils down to this "I get more bang for the buck". There is not much objectiveness when it comes to vim and emacs. You enjoy emacs, I enjoy vim.

I wish this were the case, but it is not. There is objectiveness. By learning Emacs, you are learning how to use a tool which is much more consistent and flexible. Since the learning effort is comparable, why would you choose otherwise? Concentrated effort on worthwhile tasks leads to higher returns.

>> Emacs can emulate Vim,
> A very limited form of vim navigation.

Current Emacs packages emulate Vim as far as it is useful. Cloning Vim wouldn't make sense as there are equivalent Emacs facilities.

> I didn't know about an attempt to port slime to vim, because you will have to fight vim for it, and vim won't yield. Vim doesn't do async processes and per the developers, it's not going to, period. So, no shells in the vim(you can folk a shell but then the editor goes away and when you exit the shell, you are back in the editor), no debugger, no slime...It's a conscious design decision. If you don't like it, use something else.

I acknowledge that the kitchen-sink approach of Emacs has lead to aberrations (like Gnus), at which Vim users laugh, but the superiority of Emacs would persist even if you stripped out facilities that Vim doesn't offer by design choice.

You know what, Irahul? I like Vim. Really. I have studied many Vim books and lurked on Vim Wiki and Vim enthusiast's blogs. I have never learned how to use Emacs' default editor properly, as I switched to a Vim emulator early. Emacs has an effective editor implementation, Vim has an effective editing model. That's what is objective. Thankfully, we don't have to choose anymore.

Back to work ;-)