I'm attaching a patch that provides a complete Lua [1] interface to Vim in
case anyone finds it useful. The patch is against vim-7.2. Any feedback is
welcome, of course. Disclaimer: this is my first post to the list and this is
my first patch to Vim! :)
Cheers,
Luis.
--
Computers are useless. They can only give you answers.
-- Pablo Picasso
--
Luis Carvalho (Kozure)
lua -e 'print((("lexca...@NO.gmail.SPAM.com"):gsub("(%u+%.)","")))'
Hi Luis and thanks for the patch. As I am currently evaluating Lua, so I
can invest some more time to learn the language, Lua interface seems a great
addition to vim for me. I am hoping others (Bram) feels the same too.
Below is a minor diff to your patch.
--- vim72-lua.patch 2008-09-01 10:43:13.865134252 +0300
+++ vim72-lua.patch.orig 2008-09-01 10:42:52.905306090 +0300
@@ -338,7 +338,7 @@
+ LUA_INC=
+ if test "X$vi_cv_path_lua_pfx" != "X"; then
+ AC_MSG_CHECKING(if lua.h can be found in $vi_cv_path_lua_pfx/include)
-+ if test -f $vi_cv_path_lua_pfx/include/lua.h; then
++ if test -f $vi_cv_path_lua_pfx/include/scheme.h; then
+ AC_MSG_RESULT("yes")
+ else
+ AC_MSG_RESULT("no")
Hoping to see Lua integrated into vim, again thanks.
> Cheers,
> Luis.
>
> [1] http://www.lua.org
>
> --
> Computers are useless. They can only give you answers.
> -- Pablo Picasso
>
> --
> Luis Carvalho (Kozure)
> lua -e 'print((("lexca...@NO.gmail.SPAM.com"):gsub("(%u+%.)","")))'
Regards,
Ag.
Hi Luis and thanks for the patch. As I am currently evaluating Lua, so I
can invest some more time to learn the language, Lua interface seems a great
addition to vim for me. I am hoping others (Bram) feels the same too.
Below is a minor diff to your patch.
--- vim72-lua.patch 2008-09-01 10:43:13.865134252 +0300
+++ vim72-lua.patch.orig 2008-09-01 10:42:52.905306090 +0300
@@ -338,7 +338,7 @@
+ LUA_INC=
+ if test "X$vi_cv_path_lua_pfx" != "X"; then
+ AC_MSG_CHECKING(if lua.h can be found in $vi_cv_path_lua_pfx/include)
-+ if test -f $vi_cv_path_lua_pfx/include/lua.h; then
++ if test -f $vi_cv_path_lua_pfx/include/scheme.h; then
+ AC_MSG_RESULT("yes")
+ else
+ AC_MSG_RESULT("no")
Hoping to see Lua integrated into vim, again thanks.
> Cheers,
> Luis.
>
> [1] http://www.lua.org
>
> --
> Computers are useless. They can only give you answers.
> -- Pablo Picasso
>
> --
> Luis Carvalho (Kozure)
> lua -e 'print((("lexca...@NO.gmail.SPAM.com"):gsub("(%u+%.)","")))'
Regards,
Ag.
Note to me:
Don't send again patches, when there is an angry wife near your shoulders.
--- vim72-lua.patch.orig 2008-09-01 10:42:52.905306090 +0300
+++ vim72-lua.patch 2008-09-01 10:43:13.865134252 +0300
@@ -338,7 +338,7 @@
+ LUA_INC=
+ if test "X$vi_cv_path_lua_pfx" != "X"; then
+ AC_MSG_CHECKING(if lua.h can be found in $vi_cv_path_lua_pfx/include)
-+ if test -f $vi_cv_path_lua_pfx/include/scheme.h; then
++ if test -f $vi_cv_path_lua_pfx/include/lua.h; then
Note to me:
Don't send again patches, when there is an angry wife near your shoulders.
--- vim72-lua.patch.orig 2008-09-01 10:42:52.905306090 +0300
+++ vim72-lua.patch 2008-09-01 10:43:13.865134252 +0300
@@ -338,7 +338,7 @@
+ LUA_INC=
+ if test "X$vi_cv_path_lua_pfx" != "X"; then
+ AC_MSG_CHECKING(if lua.h can be found in $vi_cv_path_lua_pfx/include)
-+ if test -f $vi_cv_path_lua_pfx/include/scheme.h; then
++ if test -f $vi_cv_path_lua_pfx/include/lua.h; then
> I'm attaching a patch that provides a complete Lua [1] interface to
> Vim in case anyone finds it useful. The patch is against vim-7.2. Any
> feedback is welcome, of course. Disclaimer: this is my first post to
> the list and this is my first patch to Vim! :)
It looks fairly complete. I hope a few people try it out and provide
feedback.
There was a patch for Lua a couple of years ago by Wolfgang Oertl, but
it appears the download link no longer works. He never finished it
anyway.
--
hundred-and-one symptoms of being an internet addict:
25. You believe nothing looks sexier than a man in boxer shorts illuminated
only by a 17" inch svga monitor.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Thank you. I'm attaching an updated version of the patch with a few more
changes. I should probably find a place to put the latest version of the patch...
Cheers,
Luis.
Thanks.
I think I've tried all the available commands and they work as they
were documented.
My only question is (from :help lua-vim):
vim.open({fname}) Opens a new buffer for file {fname} and
returns it. Note that the buffer
is not set as current.
And then few lines below:
:lua vim.open"myfile"() -- open buffer and set it as current
They both work as advertised, but why this idiom? Is there any other way
to have the same result, but to be a little bit less confusing?
If there is a reason to stay like this, at least (for me), it looks more
natural exactly the opposite, so:
lua vim.open('somefile')
it should open the file and set is as current.
> Cheers,
> Luis.
Regards,
Ag.
By the way,
I added your patch to the vim's wiki page at linuxfromscratch.org
http://wiki.linuxfromscratch.org/blfs/wiki/vim
You can create anytime an account and add the updated patch (if any), until
it will be integrated into mainline (hopefully soon).
You can click on the "attach file" and check then the "Replace existing
attachment of the same name" in the next page. Or if you want to add a
patch with a different name (preferable), click on the existing attachment
to delete it and then add the new one.
By the way,
I gave this a try on Windows. With the following patch to Make_ming.mak,
it compiles fine. I've done a couple of tests and it looks OK so far.
The only possible issue is with C runtime compatibility and loading DLLs
(compiled Lua extensions). Getting CRT versions that match is a fiddly
issue. That's nothing new for Windows Lua, though, so that's not an
issue with the patch.
Paul.
> My only question is (from :help lua-vim):
>
> vim.open({fname}) Opens a new buffer for file {fname} and
> returns it. Note that the buffer
> is not set as current.
>
> And then few lines below:
>
> :lua vim.open"myfile"() -- open buffer and set it as current
>
>
> They both work as advertised, but why this idiom? Is there any other way
> to have the same result, but to be a little bit less confusing?
> If there is a reason to stay like this, at least (for me), it looks more
> natural exactly the opposite, so:
>
> lua vim.open('somefile')
>
> it should open the file and set is as current.
I guess I've overused the syntactic sugar. The line
:lua vim.open"myfile"()
is equivalent to
:lua local b = vim.open("myfile"); b()
that is, b is the new buffer for myfile and b() sets it as the current buffer.
I didn't want to force vim.open to set the buffer to be current as that might
not be what the user wants.
Thanks for taking the time and testing if_lua!
Thanks for catching this. A new patch, that also provides a simple
configure.in, is available at
http://wiki.linuxfromscratch.org/blfs/attachment/wiki/vim/vim72-lua-0.2.patch.gz
I have a question. The standalone Lua interpreter is usually linked to a
static library, but the linker gets a -E option to export all symbols and so
dynamic modules get supported. Should I add a check for gcc and add -Wl,-E?
That would export all symbols in Vim, and so it doesn't sound like a good
idea... I could also link to a shared Lua library as default. What do you guys
think?
Hi,
First of all thanks for the patch, I've also been toying around with
Lua support in vim, but up to now it's only a sandbox for playing around
with various things both on the Lua and the vim side.
Anyway, as for your question I'd say just default to using a shared lib.
Most other interfaces seem to do so, and I'd say the costs should be
neglectable in this case. On Windows looking up the required symbols at
runtime seems to be the most popular choice, though I personally don't
care to much about it either way.
One last thing, I noticed that your patch seems to have problems with
nested compounds:
function! s:foo()
let l:things = [[1, "foo"], [2, "bar"], [3, "baz"]]
" for extra evilness:
" call add(l:things, l:things)
lua vim.eval("l:things")
endfunction
call s:foo()
Saving this as test.vim and doing vim -c 'so test.vim' causes a
segmentation fault. Same happens if I stick in a dictionary.
Flat lists seem to work flawlessly though.
Let me know if you can't reproduce this, then I'l do a debug-build
tomorrow and get you a meaningful backtrace.
Best regards
Andy
--
BOFH Excuse #239:
CPU needs bearings repacked
> Anyway, as for your question I'd say just default to using a shared lib.
> Most other interfaces seem to do so, and I'd say the costs should be
> neglectable in this case. On Windows looking up the required symbols at
> runtime seems to be the most popular choice, though I personally don't
> care to much about it either way.
That makes sense. I've updated configure.in to link a shared lib.
> One last thing, I noticed that your patch seems to have problems with
> nested compounds:
>
> function! s:foo()
> let l:things = [[1, "foo"], [2, "bar"], [3, "baz"]]
> " for extra evilness:
> " call add(l:things, l:things)
> lua vim.eval("l:things")
> endfunction
> call s:foo()
>
> Saving this as test.vim and doing vim -c 'so test.vim' causes a
> segmentation fault. Same happens if I stick in a dictionary.
> Flat lists seem to work flawlessly though.
Thanks for the report. The latest patch, available at
http://wiki.linuxfromscratch.org/blfs/attachment/wiki/vim/vim72-lua-0.3.patch.gz
should fix these issues.
1. If the interface uses a separate DLL, then the absence of that DLL
must not prevent Vim from running (as long as the interface isn't used,
of course).
2. If the DLL must be linked with the same C runtime as every program
with which it is used, there's little advantage in having a separate
DLL. It might even be outright dangerous to use it.
Therefore I believe that the way to go is to link the Lua interface (if
enabled) statically into Vim. Or else, maybe, as a DLL of a different
name, compiled and distributed together with Vim, and installed in
$VIMRUNTIME; but there might be licensing problems with the latter approach.
Best regards,
Tony.
--
Miss, n.:
A title with which we brand unmarried women to indicate that
they are in the market.
-- Ambrose Bierce, "The Devil's Dictionary"
Here is the latest patch; it includes dynamic dll loading in Windows and a few
minor tweaks:
http://wiki.linuxfromscratch.org/blfs/attachment/wiki/vim/vim72-lua-0.4.patch.gz
I've also patched the Windows makefiles:
http://wiki.linuxfromscratch.org/blfs/attachment/wiki/vim/vim72-lua-mak-0.4.patch.gz
Thanks for the comments, suggestions, and ideas, especially to Paul Moore!
> I've also patched the Windows makefiles:
>
> http://wiki.linuxfromscratch.org/blfs/attachment/wiki/vim/vim72-lua-mak-0.4.patch.gz
In this patch, for Make_bc5.mak, I have found two errors:
line 42:
> +INTERP_DEFINES = $(INTERP_DEFINES) -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL=\"lua$(PERL_VER).dll\"
LUA_VER
line 90:
>+ $(LUA_LIB_FLAG)perl.lib+
lua.lib
I have a warning, using Vim 7.2.13:
if_lua.c:
Warning W8065 if_lua.c 998: Call to function 'luaV_newstate' with no
prototype in function lua_init
I had never used lua :-)
:lua print (12 * 36)
works, but
:lua print (0 / 0)
or
:lua print (99999999 * 99999999)
crashes Vim
--
Patrick Texier
Method I: Send an email (which may be empty) from the email address with
which you are subscribed to vim-dev-u...@vim.org then wait for a
reply and make sure to do what it says.
Method II: Browse to http://groups.google.com/groups/mysubs
(you may have to log in to your Google account before you get to that
page). You'll see the Google Groups to which you are subscribed. At the
right end of the line starting "vim_dev", you see a rolldown widget
which says "E-mail". Turn it to "Unsubscribe" then click "Save group
settings" at the bottom of the page.
Note: Depending on how you subscribed, one of the above methods (I don't
know which one) may work better for you than the other.
Best regards,
Tony.
--
Any father who thinks he's all important should remind himself that
this country honors fathers only one day a year while pickles get a
whole week.
Please report any problem you have when you try the following (report = reply to
this mail):
Click the link in the footer of the mail:
> You received this message from the "vim_dev" maillist.
> For more information, visit http://www.vim.org/maillist.php
In the vim-dev section of that page, email the "To Unsubscribe" address.
John
Thanks for the report.
> I have a warning, using Vim 7.2.13:
>
> if_lua.c:
> Warning W8065 if_lua.c 998: Call to function 'luaV_newstate' with no
> prototype in function lua_init
That's weird. I haven't seen such a warning in any other compiler...
> I had never used lua :-)
>
> :lua print (12 * 36)
> works, but
> :lua print (0 / 0)
> or
> :lua print (99999999 * 99999999)
> crashes Vim
I couldn't reproduce this behavior, but I don't have Vim compiled with BCC.
In any case, the latest version of the patch that fixes Make_bc5.mak can be
found at:
http://wiki.linuxfromscratch.org/blfs/attachment/wiki/vim/vim72-lua-0.5.patch.gz
http://wiki.linuxfromscratch.org/blfs/attachment/wiki/vim/vim72-lua-mak-0.5.patch.gz
Do you mean the Lua interface or the updated Makefile?
The Lua interface is somewhere in the "new features" list. There are
too many bugs to fix at the moment, so I'm not eager to add more code
(with potential bugs).
--
Q: Should I clean my house or work on Vim?
A: Whatever contains more bugs.
Sorry, I meant the Lua interface.
"Not just yet" is fair enough. As I say, I'm manually applying the
patch myself at the moment. If I hit any issues, I'll carry on
reporting them here, and hopefully once things settle down a bit, the
patch will be reasonably well tested and suitable for inclusion then.
Paul.
Nice catch. The updated patch can be found at the usual place:
http://wiki.linuxfromscratch.org/blfs/attachment/wiki/vim/vim72-lua-0.6.patch.gz