> The problem with application-specific extension languages is that they may start underpowered and ad-hoc, whilst general purpose languages have already proved their worth and done so in several domains.
The embedded language has to be small, easy to learn, and most importantly, it should serve the purpose of extension. If it can serve other domains as well, that isn't really relevant as far as the editor is the concerned. Now vimscript doesn't do threading or evented io or thousands of other things - it isn't meant to do any of those.
> whilst GNU Emacs designers didn't reinvent the wheel and adapted a mainstream general purpose language to their needs.
Lisp can hardly be considered a mainstream, general purpose language(may be it was at the time they were adding it to emacs).
The point of vimscript wasn't to win any language design awards, but to have a langauge with a very small core which can be used for configuration and extension. As far as quirks go, all languages have quirks. PHP and JS probably have more quirks than Vimscript. 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.
viw<leader>g: Visually select a word, then grep for it.
<leader>g4w: Grep for the next four words.
<leader>gt;: Grep until semicolon.
<leader>gi[: Grep inside square brackets.
Are you saying elisp implementation of the same concept(provide me a way to grep for arbitrary grep for words, and no, spawning a shell isn't the same thing) is going to be shorter or simpler?
> While Vim users were busy wrestling with the limitations of their extension language
I would really like examples where the limitation of vimscript is outshined by elsip. Check my snippet above - vimscript is written specifically for extending vim, and it does a good job.
> Emacs users were busy churning out macros and packages for their editor.
I find recording macros in vim simpler than emacs. By default. Vim doesn't have a save macro functionality, but either you use an extension to do that, or manually save the macro.
> The main reason I have chosen Emacs as my editor is that I get more bang for the buck.
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.
> Emacs can emulate Vim,
A very limited form of vim navigation.
> whilst the opposite is not true, as the folks who tried to port SLIME (a powerful package to code in Common Lisp) realized.
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.
> 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.
> 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.
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:
> 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....
>
> 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.
The embedded language has to be small, easy to learn, and most importantly, it should serve the purpose of extension. If it can serve other domains as well, that isn't really relevant as far as the editor is the concerned. Now vimscript doesn't do threading or evented io or thousands of other things - it isn't meant to do any of those.
> whilst GNU Emacs designers didn't reinvent the wheel and adapted a mainstream general purpose language to their needs.
Lisp can hardly be considered a mainstream, general purpose language(may be it was at the time they were adding it to emacs).
The point of vimscript wasn't to win any language design awards, but to have a langauge with a very small core which can be used for configuration and extension. As far as quirks go, all languages have quirks. PHP and JS probably have more quirks than Vimscript. 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.
Consider this sample grap extension take from Steve Losh's http://learnvimscriptthehardway.stevelosh.com/chapters/34.ht...
And usage: Are you saying elisp implementation of the same concept(provide me a way to grep for arbitrary grep for words, and no, spawning a shell isn't the same thing) is going to be shorter or simpler?> While Vim users were busy wrestling with the limitations of their extension language
I would really like examples where the limitation of vimscript is outshined by elsip. Check my snippet above - vimscript is written specifically for extending vim, and it does a good job.
> Emacs users were busy churning out macros and packages for their editor.
I find recording macros in vim simpler than emacs. By default. Vim doesn't have a save macro functionality, but either you use an extension to do that, or manually save the macro.
> The main reason I have chosen Emacs as my editor is that I get more bang for the buck.
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.
> Emacs can emulate Vim,
A very limited form of vim navigation.
> whilst the opposite is not true, as the folks who tried to port SLIME (a powerful package to code in Common Lisp) realized.
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.