> Vim Script started as a hack and continued that way, with further functions being added on a "as-needed" basis.

Why shouldn't adding functions on "as-needed" basis be the case? No body can see what might be needed in the future. All programming languages evolve, so does vimscript. Other languages evolve in favor of language design and libraries, vimscript adds things which are needed.

> 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.

"Perl fallacy" isn't something accepted and proved. It's mostly Python and Ruby folks bashing perl. I have written substantial amount of perl, python, ruby(and lots others, but these 3 are almost interchangeable) and I find perl easy to read and write.

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

You said it yourself, and I will repeat it. Vimscript exists only to extend vim, and everything that's added to it is added with that in mind. Anything that helps vimscript better at extending vim is good, anything else is not bad but is irrelevant.

> 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?

Well then there has got to be a reason we don't have this magical framework yet which we can use for everything. May be "right tool for the job"?

> Evidence shows that Emacs' packages can go beyond Vim's

Would love to look at some of that evidence. Apart from async stuff(debuggers, slime etc), I don't think that should be the case. I have looked at Tim Pope's and scrooloose's vim plugins, and have reasonable experience writing vimscript and looking at others' work to believe vimscript is powerful enough for the job.

> 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.

http://code.google.com/p/go/source/browse/misc/emacs/go-mode...

Look at the syntax highlighting section 28-107 and show me where it's parsing go code. I don't know what you meant by "parse and understand code", but a parser for a non-toy language isn't something you write in elisp for a syntax highlighter.

Syntax highlighters more or less work the same way. You have a colorscheme which says keywords are blue, and then the highlighter tells what is to be considered a keyword. Now keywords is cakewalk - a static list of tokens, and in most editors, if you name your variable `class`, it gets the same highlighting as the keyword class. Regions(multi-line comments, multi-line strings, function arguments falling down to next line) are a bit problematic, but editors have hooks for it.

# Well, thank's slosh again.
# http://learnvimscriptthehardway.stevelosh.com/chapters/47.html
syntax region potionString start=/\v"/ skip=/\v\\./ end=/\v"/
highlight link potionString String

Now,

"She said:
\"Vimscript is tricky, but useful\"!".

will highlight as string just fine.

> 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.

It is difficult to read to whom? Unless it is difficult to read to someone who knows vimscript, it doesn't matter.

You are missing the point. When I am in the editor, and I need to copy 2 words, I do y2w. Making it a function call in vimscript isn't beneficial to me at all. What exactly would I gain if vimscript, instead of this:

normal! `<v`>y

gave me a well-named function to call:

copy_visual_mode_range_to_default_register()

How does it matter to me copy_visual... is more readable than `<v`>y to someone who doesn't use vim? Oh, vimscript has functions, lots of them http://vimdoc.sourceforge.net/htmldoc/usr_41.html#function-l...

But everytime I need them, I have to look them up, compared to vim normal mode and other commands which I already know and use in the editor.

> There is objectiveness. By learning Emacs, you are learning how to use a tool which is much more consistent and flexible

Unless you have objective proof of "emacs being much more consistent and flexible(where, how)" it's not objective at all.

> but the superiority of Emacs

Again, citations needed.

> Emacs has an effective editor implementation, Vim has an effective editing model. That's what is objective.

No, it's still not objective. You just delcared "vim has effective editing model" and "emacs has effective editor".

> Back to work ;-)

The only thing that matters.