4 ms·

> Vimscript is not a general purpose programming language, but does the job of extending vim fine. If you have the chance to choose to invest time in learning

by lelele 14y ago

> Vimscript is not a general purpose programming language, but does the job of extending vim fine. If you have the chance to choose to invest time in learning either a language to extend your editor or a general purpose language which you can use to extend your editor, which would be your best bet?

irahul 14y ago
> If you have the chance to choose to invest time in learning either a language to extend your editor or a general purpose language which you can use to extend your editor, which would be your best bet? It's not as uni-dimensional. Sure if I don't know either of Vimscript or Python, I will see learning Python as more beneficial. But the main reason vim chose vimscript(or emacs chose elisp) is you have a interpreter built in the editor itself. If all your extensions are vimscript, all you need to configure vim on a new box is to copy your .vimrc and .vim folder and everything will work - no package installation, no external dependencies. If you already know vim and some programming, you can start writing basic vimscript in an hour or two. The more complicated ones(the ones Time Pope writes) are going to take a lot of time, irrespective of your language choice. Also, vim extensions can be written in Python as well, but it requires that your vim has python support. How does ST does it? Does it bundle python?
- lelele 14y ago
  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. Vim designers tried to reinvent the wheel and failed to implement a decent extension language from the beginning, whilst GNU Emacs designers didn't reinvent the wheel and adapted a mainstream general purpose language to their needs. So, while Vim users were busy wrestling with the limitations of their extension language and coping by adding ad-hoc extensions here and there, Emacs users were busy churning out macros and packages for their editor. The main reason I have chosen Emacs as my editor is that I get more bang for the buck. Emacs can emulate Vim, whilst the opposite is not true, as the folks who tried to port SLIME (a powerful package to code in Common Lisp) realized. We agree that an embedded extension language is the way to go. And whatever mainstream language you might choose, it could go out of fashion after a while anyway.
  - irahul 14y ago
    > 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. Consider this sample grap extension take from Steve Losh's http://learnvimscriptthehardway.stevelosh.com/chapters/34.html http://learnvimscriptthehardway.stevelosh.com/chapters/34.ht... nnoremap <leader>g :set operatorfunc=<SID>GrepOperator<cr>g@ vnoremap <leader>g :<C-U>call <SID>GrepOperator(visualmode())<cr> function! s:GrepOperator(type) let saved_unnamed_register = @@ if a:type ==# 'v' normal! `<v`>y elseif a:type ==# 'char' normal! `[v`]y else return endif silent execute "grep! -R " . shellescape(@@) . " ." copen let @@ = saved_unnamed_register endfunction And usage: 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.

by lelele 14y ago

irahul 14y ago

> If you have the chance to choose to invest time in learning either a language to extend your editor or a general purpose language which you can use to extend your editor, which would be your best bet? It's not as uni-dimensional. Sure if I don't know either of Vimscript or Python, I will see learning Python as more beneficial. But the main reason vim chose vimscript(or emacs chose elisp) is you have a interpreter built in the editor itself. If all your extensions are vimscript, all you need to configure vim on a new box is to copy your .vimrc and .vim folder and everything will work - no package installation, no external dependencies. If you already know vim and some programming, you can start writing basic vimscript in an hour or two. The more complicated ones(the ones Time Pope writes) are going to take a lot of time, irrespective of your language choice. Also, vim extensions can be written in Python as well, but it requires that your vim has python support. How does ST does it? Does it bundle python?

lelele 14y ago
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. Vim designers tried to reinvent the wheel and failed to implement a decent extension language from the beginning, whilst GNU Emacs designers didn't reinvent the wheel and adapted a mainstream general purpose language to their needs. So, while Vim users were busy wrestling with the limitations of their extension language and coping by adding ad-hoc extensions here and there, Emacs users were busy churning out macros and packages for their editor. The main reason I have chosen Emacs as my editor is that I get more bang for the buck. Emacs can emulate Vim, whilst the opposite is not true, as the folks who tried to port SLIME (a powerful package to code in Common Lisp) realized. We agree that an embedded extension language is the way to go. And whatever mainstream language you might choose, it could go out of fashion after a while anyway.
- irahul 14y ago
  > 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. Consider this sample grap extension take from Steve Losh's http://learnvimscriptthehardway.stevelosh.com/chapters/34.html http://learnvimscriptthehardway.stevelosh.com/chapters/34.ht... nnoremap <leader>g :set operatorfunc=<SID>GrepOperator<cr>g@ vnoremap <leader>g :<C-U>call <SID>GrepOperator(visualmode())<cr> function! s:GrepOperator(type) let saved_unnamed_register = @@ if a:type ==# 'v' normal! `<v`>y elseif a:type ==# 'char' normal! `[v`]y else return endif silent execute "grep! -R " . shellescape(@@) . " ." copen let @@ = saved_unnamed_register endfunction And usage: 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.