> 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

> 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. When you add things when needed instead of thinking them through beforehand, you have two choices: - forsaking backward compatibility, thus breaking existing libraries; - striving for backward compatibility, thus ending up with an inconsistent framework and language quirks. Examples are not rare: - Perl and its flattened lists and many other quirks; - PHP; - Python warts; - C++ with weird syntax which is legit; - etc. > 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. Props, man. You must have a big brain, if you feel that both Python and Perl have almost the same cognitive load. I considered myself to be a sharp blade at programming C++, yet I have always found it to be a taxing task. Good for you. I'm not joking. > 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. But you can't deny that an extension language which goes beyond its editor comes with a bonus. > 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"? Such magical framework exists. Its name is GNU Emacs. Sometimes its magic has been overplayed, but still... >> 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. What about: - Gnus, RM, VM, Vanderlust, Meow: mail readers (IMO an aberration, but it proves the point); - Eshell (Emacs shell, written in Emacs Lisp); - Dired, Sunrise Commander: file browsers; None of these packages uses functionality which is alien to Vim, except a more expressive extension language and a richer library. > http://code.google.com/p/go/source/browse/misc/emacs/go-mode.. 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. That's a basic Emacs mode. Throw some Perl code to both CPerl in Emacs and to Vim and see which of the two copes better (with Perl you can't do better than coping). >> 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. It is difficult to read to everyone. There is a reason for we using named variables instead of codes of registers nowadays. > 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 happens if the reader has remapped such keys on his Vim? I don't know, but either your code will break or the user will risk misunderstanding it. Maybe Vim doesn't offer you any facility to easily convert keyboard macros to named procedures, therefore you have to resort to hardcode such macros. What if the reader uses a subset of Vim's commands and doesn't recognize the hard-coded macro at first sight? She has to decrypt it. In Emacs Lisp, you always have at least clue about what a command does. >> Unless you have objective proof of "emacs being much more consistent and flexible(where, how)" it's not objective at all. That Emacs is more flexible, I have proved. Documenting why Emacs is more consistent would be more work than I'm willing to put into a comment here. Since I have studied both Vim and Emacs and read experiences of users who have switched from one to the other, both ways, I believe I have a good idea about how they stack one against the other. I accept that you don't share my opinion. >> Back to work ;-) > The only thing that matters. But a flame war is often a welcomed distraction. Cheers.