[sophacles]

Ive always thought Lua would be a good vim scripting language.

* It's designed to be embedded

* It's easy to expose functionality and API's

* It's fast

* IME if other languages are also embedded, and a thoughtful API/plugin arch is created, functionality from other language plugins can be easily accessed in lua. (I know, bunch of caveats there, but if I'm dreaming...)

[hsitz]

Vim supports scripting with Lua similar to the support it already has for Python, Perl, Ruby, Racket. Your instance of Vim just has to be compiled with that option. See ':h lua'. One major problem with its support for scripting languages has been that you can't count on other users having a Vim compiled with proper support. This includes Python, although more recently some distributions (e.g., I think, Ubuntu) have had standard Vims where Python support was by default compiled in. Apparently improvements to Python interface in 7.4 will go beyond those currently offered for outside languages, which many find somewhat clunky.

[gnosis]

99% of vim scripts still use VimScript.

I think this happens for a few reasons:

  - First, as you pointed out, not every user is guaranteed
    to have your favorite language installed.  But they will
    have VimScript whenever they use vim.

  - Second, even if a user has your favorite language
    installed, the version of vim they have might not be
    compiled with bindings for that language.  Only VimScript
    is guarateed to be compiled in.

  - Third, VimScript is the only language in vim that's not
    crippled in some way in respect to functionality.  All
    the other languages it supports have to rely on
    VimScript itself in order to perform some vim-related
    functions.  In some languages, this makes it so that you
    might as well be using VimScript to begin with.

[siddboots]

#2 has been the biggest drawback in my experience. It often isn't realistic to compile your editor from scratch, particularly when you are working in a windows environment without administrator rights to your machine. This means that any extensions (e.g. dbext) dependent on those bindings are unavailable.

Is there a reason why there is no portable binary compiled with bindings for perl, python, lua, et cetera?

[sophacles]

Oh yeah, the Lua support is there, I was meaning a concentrated effort to have Lua replace VimScript completely.

[pyre]

  | although more recently some distributions

Even CentOS 4 had a Vim with python in it. The issue that I always came up against was Ruby support. Ruby wasn't compiled in, and some Vim plugins (e.g. LustyExplorer, FuzzyFinder) relied on it. I worry less about that now that Ctrl-P (written in Vimscript) has replaced those for me.

[Avshalom]

only thing about Lua is that strings are immutable so certain kinds of operations can be very slow.

[hetman]

They are also immutable in Python.

[ShawnBird]

What are you talking about?

http://docs.python.org/2/library/string.html

[pyre]

  >>> a = "string"
  >>> a[1] = 'g'
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: 'str' object does not support item assignment
  >>> b = a.replace('t', 'g')
  >>> b
  'sgring'
  >>> a
  'string'
  >>> id(b)
  3065252256L
  >>> id(a)
  3075481632L

Also from here[1]:

  Strings and tuples are immutable sequence types: such
  objects cannot be modified once created.

[1] http://docs.python.org/2/library/stdtypes.html#mutable-seque...

[ShawnBird]

Oh. I guess I never thought of strings as immutable because there are so many ways to change them.

[noselasd]

Given that they're immutable, you cannot change them. Instead all the operations returns a new, modified, string.