Danek Duvall wrote: > On Mon, Jun 26, 2006 at 10:22:17AM -0700, Stephen Hahn wrote: > > >> I would probably argue that #vim is a bit self-selecting, if one is >> looking for sophisicated users. If you instead search the published >> scripts on vim.sf.net to assess usage, it's pretty clear that native >> scripts are dominant, then there are a number using Perl or Python, >> and then an even smaller group using Ruby or Tcl. >> > > I imagine that most script writers are trying to be as inclusive as > possible. There's a chicken and egg problem here -- if a sufficiently > large percentage of vim packages don't have support for the alternate > languages, then a very small percentage of people will publish scripts for > them. > > >> My objection is a little bit about size, but mostly that the Vim >> maintainer(s) will have to redeliver (or evaluate the need to >> redeliver) when any of the included interpreters are updated. More >> interpreters means more work for the maintainer(s); all I suggest is >> that the maintainer calculate that cost... >> > > It might also be worth checking to see whether factoring out the languages > into shared objects would be a savings.
A savings in executable size, but not maintenance cost though, right? > Looking at the python code, at > least, seems like the amount of work involved would be minimal. I've no > idea whether Bram would take the change back, though, but that would > probably be a quick question to ask. > > Danek >
