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 https://github.com/martanne/vis/pull/1114 (and made a slightly more complicated in https://github.com/martanne/vis/pull/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.

[mcepl]

@Nomarian ping?

[mcepl]

Is https://git.sr.ht/~mcepl/vis/commit/f5af8783cc2255efbc4db5ffe319126db6350213 the fix?

diff --git a/test/lua/win_open_options.lua b/test/lua/win_open_options.lua
new file mode 100644
index 00000000..6a701853
--- /dev/null
+++ b/test/lua/win_open_options.lua
@@ -0,0 +1,8 @@
+-- Regression test for https://github.com/martanne/vis/issues/1230
+-- Ensure win.options is initialized before WIN_OPEN event
+
+vis.events.subscribe(vis.events.WIN_OPEN, function(win)
+	if win.options == nil then
+		error("win.options should not be nil on WIN_OPEN")
+	end
+end)
diff --git a/vis.c b/vis.c
index 08ee6b2f..0a8f94eb 100644
--- a/vis.c
+++ b/vis.c
@@ -28,6 +28,7 @@
 #include "vis-core.h"
 #include "sam.h"
 #include "ui.h"
+#include "options.h"
 #include "vis-subprocess.h"
 
 
@@ -373,6 +374,12 @@ Win *window_new_file(Vis *vis, File *file, enum UiOption options) {
 	Win *win = calloc(1, sizeof(Win));
 	if (!win)
 		return NULL;
+
+	/* initialize options before events are fired */
+	win->options = options_new(vis);
+	if (!win->options)
+		goto err;
+
 	win->vis = vis;
 	win->file = file;
 	if (!view_init(win, file->text)) {

[Nomarian]

options.h doesnt exist

[mcepl]

I have no idea, what I did. This patch doesn't make any sense, the solution seems to be a way more complicated. It will take a bit time before I develop it and fix it.

[Nomarian]

Oh good I was going crazy looking for it

[mcepl]

What about this 0001-window-always-initialize-win-options-before-WIN_OPEN.patch ?

This at least builds and test is passing.

[mcepl]

There is a nasty crash there, fixed (hopefully, not tested at all) with 0002-lua-Correct-runtime-crash-in-options-object-handling.patch

[mcepl]

Fixed version of the patch was sent to the list https://lists.sr.ht/~martanne/devel/patches/62149 , further updates, if any, will be sent there.

[mcepl]

On Tue Sep 16, 2025 at 3:54 PM CEST, lan Nomar wrote:

I have copied your branch from sr.ht, just sent me a notice and I'll pull and test

Sorry, I don’t understand what’s my action item here. What am I expected to do?

Best,

Matěj

http://matej.ceplovi.cz/blog/, @@.*** GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8

The main idea of the pope’s asking for forgiveness was not to be afraid of the truth. DO NOT BE AFRAID OF TRUTH! We have to have faith in the God’s governing power to be able not to be afraid. -- On NPR The Connection from March 13, 2000