Invalid window id Issue with NuiSplit

[MunifTanjim]

Possibly one thing;

Suppose there are two windows (1 and 2) side by side. When I make a new NuiSplit({ relative = "editor" }):mount() (creates 3), it opens at the most left(/right) position.
Inside :update_layout() inside :init(), self._.relative is changed to { type = "editor", win = 1 }.

After that, I split:hide() and then delete window 1.

When I call split:show() after that, the value in self._.relative.win is required here, and since window 1 is already deleted, :show() will fail.

To workaround this issue, I need to call split:update_layout() before split:show() to ensure self._.relative.win is a valid window.

When I'm making a split relative to the editor, I suppose the code shouldn't matter where to spawn the window from, so it would be more intuitive if I didn't need to call update_layout. (And it took quite a lot of time to figure out...)

It would be nice if you could add some if-else based on relative settings or possibly put a caution in the document?

orignally posted by @pysan3 in #295 (comment)

[MunifTanjim]

@pysan3 Can you try changing this

nui.nvim/lua/nui/split/init.lua

Line 168 in 35da9ca

self.winid = vim.api.nvim_win_call(self._.relative.win, function()

to

  self.winid = vim.api.nvim_win_call(self._.relative.type == 'editor' and 0 or self._.relative.win, function()

and see if that works?

[pysan3]

Yep ;)

Ideally, we would like to keep self._.relative.win to 0 while self._.relative.type == "editor" which is modified here.

nui.nvim/lua/nui/split/utils.lua

Lines 132 to 152 in af7dfee

	if internal.relative and internal.relative.win and not vim.api.nvim_win_is_valid(internal.relative.win) then
	internal.relative.win = vim.api.nvim_get_current_win()
	internal.win_config.win = internal.relative.win
	internal.win_config.pending_changes.relative = true
	end
	if options.relative then
	local fallback_winid = internal.relative and internal.relative.win or vim.api.nvim_get_current_win()
	internal.relative = parse_relative(options.relative, fallback_winid)
	local prev_relative = internal.win_config.relative
	local prev_win = internal.win_config.win
	internal.win_config.relative = internal.relative.type
	internal.win_config.win = internal.relative.type == "win" and internal.relative.win or nil
	internal.win_config.pending_changes.relative = internal.win_config.relative ~= prev_relative
	or internal.win_config.win ~= prev_win
	end

But I'm not 100% sure if self._.relative.win == 0 does cause issues / make breaking changes to existing code.

NuiPopup is dealt here in a different place btw.

nui.nvim/lua/nui/layout/utils.lua

Lines 137 to 147 in af7dfee

	if options.relative then
	internal.layout.relative = options.relative
	local fallback_winid = internal.position and internal.position.win or vim.api.nvim_get_current_win()
	internal.position =
	vim.tbl_extend("force", internal.position or {}, mod.parse_relative(internal.layout.relative, fallback_winid))
	win_config.relative = internal.position.relative
	win_config.win = internal.position.relative == "win" and internal.position.win or nil
	win_config.bufpos = internal.position.bufpos
	end

[pysan3]

Seems like we do need this fixed as I still experience invalid window error with noice.

@MunifTanjim

  self.winid = vim.api.nvim_win_call(self._.relative.type == 'editor' and 0 or self._.relative.win, function()

I think your suggestion is good enough.

And looking forward to seeing a new version release as well :)

[MunifTanjim]

Sorry, I couldn't find the time to fix this. If you open a PR I'd be happy to review and merge it.

[pysan3]

#337

[pysan3]

May I ask you why you reference relative.winid here?

nui.nvim/lua/nui/split/utils.lua

Line 68 in af7dfee

local winid = u.defaults(relative.winid, fallback_winid)

Called from

nui.nvim/lua/nui/split/utils.lua

Line 142 in af7dfee

internal.relative = parse_relative(options.relative, fallback_winid)

If I'm not mistaken, options.win the only thing user can pass according to the type annotations. Or am I missing something?

[pysan3]

But that code has been there for more than an year, and I'm not brave enough to blindly fix it lol.

I'll hand it to you to decide and fix the problem.

[MunifTanjim]

Okay so the type annotation is wrong. This is the doc:

nui.nvim/lua/nui/split/README.md

Lines 46 to 53 in af8ddf5

	Split window with specific id:
	```lua
	relative = {
	type = "win",
	winid = 42,
	}
	```

[pysan3]

Ah, that's why my hand always typed winid there, although my brain told me to write win.

My hands remembered the old era with no type annotations lol.

[MunifTanjim]

Should be fixed now.

[pysan3]

@MunifTanjim
7da355e#commitcomment-138737872