lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


I'd say drop bool support. I believe it's not that much harder to
implement and would avoid arcane bugs from less responsible Lua
coders.

BTW, great idea making this bridge. I'd love to troll around with my
vim from Lua.

On 9/14/11, Rob Hoelz <rob@hoelz.ro> wrote:
> Hello everyone,
>
> I'm currently working on a better bridge between Lua and Vim to make it
> easier to write Vim plugins in Lua.  However, during my implementation
> of this, I've hit a bit of a snag and was hoping for some insight from
> other Lua users.
>
> Vimscript uses prefixes to address different variable scopes; for
> example, to set the 'foo' variable for the current window, I'd do this:
>
>   let w:foo = 17
>
> My plugin exposes this feature in a very Lua-esque manner:
>
>   w.foo = 17
>
> Until now, it has only worked with numbers, strings, and nil.  One of
> the next things I plan on doing with this plugin is adding support for
> assigning booleans.  Vimscript, however, doesn't have the notion of
> boolean; 0 is false and all other values are true (I think).  When it
> comes to simple assignment, this is trivial; just convert Lua's true to
> 1 and Lua's false to 0.  However, when it comes to retrieving the
> value, it gets more complicated.  For example, a Vimscript plugin could
> set a global flag:
>
>   let g:my_flag = 1
>
> When I call 'g.my_flag' from Lua, should it return a number or a
> boolean?
>
> Even if I don't worry about this, there's another issue.  Let's say I
> assign a boolean to a variable in my current window:
>
>   w.my_variable = true -- Vim sees this as let w:my_variable = 1
>
> Now, when I read from that variable, what do I see?
>
>   print(w.my_variable) -- does this output true, or 1?
>
> My current ideas on how to handle these issues are as follows:
>
> - Drop support for booleans entirely.  Scripts are free to use
>   them for their own logic, but anything going/coming across the bridge
>   is a number.  This means 'w.my_variable = true' will fail, and when
>   calling Vim functions, we'll have to use a foreign-looking idiom such
>   as if haslocaldir() ~= 0 then ... end.
>
> - Assigning booleans to Vim variables will coerce them to Vim numbers,
>   but no coercion will take place on the way back.  We'll need to use
>   constructs like if w.my_variable ~= 0 then ... end or if
>   toboolean(w.my_variable) then ... end.  However, Vim functions that
>   are known to return boolean values can coerce their outputs to
>   boolean, so we can still do if haslocaldir() then ... end.
>
> - Remember which variables I assign booleans to, and treat them as
>   such.  If I assign w.my_variable = true, the bridge will coerce the
>   value of w:my_variable to a boolean when reading it, until a
>   non-boolean value is assigned to that variable from Lua.
>
> For those of you who are interested in taking an early look at this
> project, its Git repository is located here:
>
> https://github.com/hoelzro/queqiao
>
> Any thoughts?
>
> Thanks,
> Rob
>

-- 
Sent from my mobile device

NI!