6 ms·

>> It uses Python as its scripting language, so you can use Python libraries easily, and don’t have to learn an editor-specific language. Similarly, it uses JSO

by lparry 14y ago

>> It uses Python as its scripting language, so you can use Python libraries easily, and don’t have to learn an editor-specific language. Similarly, it uses JSON for settings. >Python is much more mainstream than vimscript, yes, but there are still people who don't know python and don't want to learn it. Learning python for them isn't very different from learning vimscript. You've quite obviously never tried to code anything in vimscript, have an axe to grind with Python, or are Tim Pope. Vimscript is a horrible abomination that's painful to do just about anything in. Python is far, far superior. (Vim lover and Ruby guy here, but I'd pick just about any language over vimscript)

irahul 14y ago
> You've quite obviously never tried to code anything in vimscript, have an axe to grind with Python, or are Tim Pope All your claims are preposterous. I have coded in Vimscript, I use Python and have no axe to grind; and I am not Tim Pope(duh). > Vimscript is a horrible abomination that's painful to do just about anything in. Python is far, far superior. I don't remember claiming Python is inferior to vimscript. Have you actually used vimscript, or are you speaking from superficial experience? Vimscript is not a general purpose programming language, but does the job of extending vim fine. I was in middle of writing a small function which syncs up nerdtree highlighting with bufexplorer buffer switch(came here to take a break). Here is what it looks like: function! ChangeBuffer() if bufwinnr(t:NERDTreeBufName) != -1 exe "normal! :NERDTreeFind\<cr>\<c-w>\<c-w>" endif endfunction let g:BufExplorerFuncRef = function('ChangeBuffer') The amount of general purpose programming involved is minimal. 1. BufExplorer provides a hook which takes a function reference. A variable assignment. 2. If nerdtree is active(simple function call), call the command to find the current buffer in nerdtree(vim specific normal command execution), and switch back to editing pane(again normal mode command) A good part of tasks make use of exe, nnoremap, iabbrev etc; and vimscript is powerful and pleasant enough for the rest(lists, dicts, simulated objects, variable namespacing...). It has it's quirks, but so has many mainstream languages - you know about the quirks when you are using the language, and avoid them.
- 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.

by lparry 14y ago

irahul 14y ago

> You've quite obviously never tried to code anything in vimscript, have an axe to grind with Python, or are Tim Pope All your claims are preposterous. I have coded in Vimscript, I use Python and have no axe to grind; and I am not Tim Pope(duh). > Vimscript is a horrible abomination that's painful to do just about anything in. Python is far, far superior. I don't remember claiming Python is inferior to vimscript. Have you actually used vimscript, or are you speaking from superficial experience? Vimscript is not a general purpose programming language, but does the job of extending vim fine. I was in middle of writing a small function which syncs up nerdtree highlighting with bufexplorer buffer switch(came here to take a break). Here is what it looks like: function! ChangeBuffer() if bufwinnr(t:NERDTreeBufName) != -1 exe "normal! :NERDTreeFind\<cr>\<c-w>\<c-w>" endif endfunction let g:BufExplorerFuncRef = function('ChangeBuffer') The amount of general purpose programming involved is minimal. 1. BufExplorer provides a hook which takes a function reference. A variable assignment. 2. If nerdtree is active(simple function call), call the command to find the current buffer in nerdtree(vim specific normal command execution), and switch back to editing pane(again normal mode command) A good part of tasks make use of exe, nnoremap, iabbrev etc; and vimscript is powerful and pleasant enough for the rest(lists, dicts, simulated objects, variable namespacing...). It has it's quirks, but so has many mainstream languages - you know about the quirks when you are using the language, and avoid them.

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.