Re: Lua file type plug-in for Vim

Thank you Taylor and Jerome for your feedback. Because you brought up
some of the same issues I'll reply to you both here.

Taylor Venable wrote:
>> * <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.

Yeah, if I want this file type plug-in included with the Vim runtime
files I'll probably have to disable the <F1> mapping by default because
it's already used by Vim. Note however that if the Lua Reference for Vim
isn't installed or no matching topic can be found then the mapping falls
back to Vim's default behavior (execute :help help.txt).

Jerome Vuarand wrote:
> I'm not a very advanced vim user, so I don't know how to test most of
> the features you added. However here are a few glitches on Vim 7.1 on
> Windows:

Because I wrote the file type plug-in for myself I didn't need any docs.
When I posted the plug-in to the list I added some in-line notes but
these aren't very useful to users of the plug-in. When I post the next
version to the list I will include documentation on how the features
provided by the plug-in can be used.

> - the % jump on function/if/for/etc. just doesn't work (is there
> something to do to turn it on?)

This functionality uses the matchit plug-in, which is included with Vim
but not enabled by default because of backwards compatibility with Vi.
The Vim docs explain how to enable the matchit plug-in, to read it
execute the following command from inside Vim: ":help matchit-install".

Taylor Venable wrote:
>> * 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.

It should happen automatically if your Vim install supports automatic
commands and you have the luac program in your path. Since posting the
plug-in I've added some checks that make sure luac exists. Maybe the new
version would have given you an error message instead :).

It can already be disabled in the copy of the plug-in that I posted to
the list by setting the global variable 'lua_check_syntax' to zero:

let lua_check_syntax = 0

Maybe it would be better to disable this functionality by default and
let the user enable it when (s)he chooses to do so?

Jerome Vuarand wrote:
> when saving my file, with no luac in the path, the logical cursor is
> moved to the first non-white character of the current line, which is
> very annoying

I agree with you that the automatic command shouldn't move the cursor
when luac isn't available or there are no errors. I've already fixed
this in my local copy. If you want to use the plug-in right now but
don't like this behavior see the note about the 'lua_check_syntax'
variable above.

> also in the same condition as above, in insert mode, the visual cursor
> is moved to the end of the status line (where the successful saving is
> reported), which makes it impossible to know what the current mode and
> logical cursor position

I'm not sure I understand this. My visual cursor also jumps to the
status line when Vim is busy running automatic commands, but the cursor
returns to the buffer when the automatic commands finish. Does this not
happen for you or have I misunderstood you?

Taylor Venable wrote:
> 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.

It appears I misunderstood the Vim docs when reading about text objects.
They are indeed repeatable. I'm working on making them so right now.

> 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.

These are both bugs on my part. I've found getting the text objects to
work correctly is really hard, amongst other things because Lua
overloads 'end'.

I'll post an improved version of the plug-in to the list soon!

- Peter Odding