win.options is nil on WIN_OPEN event

[Nomarian]

Problem

win.options is nil on WIN_OPEN event

Steps to reproduce

No response

vis version (vis -v)

0.8

Terminal name/version

No response

$TERM environment variable

No response

[mcepl]

Yes, it is correct, I had to start my configuration as this:

vis.events.subscribe(vis.events.WIN_OPEN, function(win)
›   win.options = { tabwidth = 4, autoindent = true }
›   for k,v in pairs({
›   ›   showtabs = true,
›   ›   expandtab = true,
›   }) do win.options[k] = v end 
end)

[Nomarian]

Then perhaps this should be added to vis-std.lua?

[mcepl]

Well, the question is what exactly should be the content of this table? Default values?

[Nomarian]

Probably Both

http://martanne.github.io/vis/doc/#vis.options
http://martanne.github.io/vis/doc/index.html#window.options

vis.options also doesn't exist in my vis. or at least when I tried to write to a write the table to a file it was empty.

I do not know if the table exists in the C side or if it can be replaced with lua.

[mcepl]

I do not know if the table exists in the C side or if it can be replaced with lua.

Lua access to options was introduced in #1114 (and made a slightly more complicated in #1127).

[rnpnr]

I do not know if the table exists in the C side or if it can be replaced with lua.

Neither table exists in lua. vis.options and win.options exist so that there is a single location that you can assign a lua table to and have the values propagate to the appropriate storage location. The actual members are pushed only when specifically requested.

I had a much worse understanding of how to bind C stuff to Lua when I wrote that code. I now know how to fix it. The only question I have is if we should still support he alternate names (eg. "autoindent" and "ai"). I'm fairly certain we only want the full name in the lua table that is returned when you call win.options or vis.options but with additional code we could still support the case where the user explicitly requests win.options.ai for example.

As for setting the values I don't see any reason to change what is already happening but if we decide to remove the short names they should probably also be removed here.

[Nomarian]

I think removing the short names in the lua api is the way to go and instead leave the set command to handle the aliases. Otherwise .options. would be a proxy metatable, of course, given that its userdata, I suppose one doesn't have to worry about lua idiosyncrasies.

Also does vis.options now contain the defaults then? and those propagate to win.options? does :set only set the current window or is it the global default or both? what if you just want to set the global or just the window?

[mcepl]

+1 to @Nomarian If nothing much changes from the :set command user perspective, then I am all for making these tables API-like (i.e., unequivocally defined and well documented).

And yes, the clear delineation (both in the man page and in the API docs) what is in win.options and what is in vis.options would be very helpful.