Re: Lua file type plug-in for Vim

[Taylor Venable <taylor@...>]

On Wed, 20 Aug 2008 22:45:07 +0200
Peter Odding <xolox@home.nl> wrote:

> An overview of the significant things my file type plug-in will do to 
> your beloved Vim configuration (when your editing Lua source code):

This looks cool.  Clearly you put a lot of time into this, so I'm going
to go through and list my comments one-by-one.

>   * The 'includeexpr' option is set so that the gf (go to file)
> mapping knows how to resolve Lua module names using the $LUA_PATH.

This seems to be working for me.

>   * The 'include' option is set so that Vim follows dofile(), loadfile
> () and require() calls when looking for identifiers in included files
> (this works together with the 'includeexpr' option).

This also works.  I wonder though about the semantics of [i. Now, I
hardly ever use this feature, but I think that [i is supposed to show
the first result from [I, which is what happens with C code but not
with this Lua.  (For example, [i found the definition whereas [I found
that an invocation appears before the definition in the same file.)

>   * An automatic command is installed that runs 'luac -p' when you
> save your Lua scripts. If luac reports any errors they are shown in
> the quick-fix list and Vim jumps to the line of the first error.

Does this happen automatically?  It doesn't seem to work for me.  If
the intention is to make it always on, I recommend allowing the user to
switch it off.  For example, I might often save my file knowing full
well that it's not syntactically correct, and I don't want the cursor
to jump around on me.

>   * <F1> on a Lua function or 'method' call will try to open the 
> relevant documentation in the Lua Reference for Vim [2].

I didn't test this, but I think generally rebinding <F1> is a bad idea,
since it is already a fairly important and standard shortcut.

>   * The 'usercomplete' option is set to allow completion of Lua 5.1 
> keywords, global variables and library members.

This seems to work quite well.

>   * A bunch of 'text object' mappings are included so you can jump 
> between blocks and functions.

It would be nice if [[ were repeatable.  Right now it gets stuck on
"function".  To match the functionality for C, Java, etc. you should be
able to keep hitting [[ and keep going up.  Same goes for the other
movement keystrokes.

Another little problem: [] should take me back to the last 'end' at the
end of a function, but it takes me to the 'function' part instead.

Also, [[ and ][ don't work outside of function blocks.

>   * A pretty nifty hack of the matchit plug-in is included: When the 
> cursor is on a 'function' or 'return' keyword the % mapping cycles 
> between the relevant 'function', 'return' and 'end' keywords.
> Likewise for branching statements (if, elseif, else, end) and looping
> statements (for, while, repeat, until, end).

This is neat!  I haven't been able to confuse it yet.

> I hope you like it!

I do, great work!  I look forward to the official release.  Let me know
if there's anything I can do to help provide reproduction information,
etc.  All in all, it is nice but has a few kinks as noted above.

-- 
Taylor Venable            http://real.metasyntax.net:2357/

foldr = lambda f, i, l: (len(l) == 1 and [f(l[0], i)] or
                         [f(l[0], foldr(f, i, l[1:]))])[0]