Wezterm active pane not undimming

[ir-ae]

Thank you for adding Wezterm support, its something I've wanted in Neovim for a while and it mostly works as expected. The only issue I'm having is when navigating from Neovim back to Wezterm, the inactive styling and cursor style don't change until the next keypress which momentarily makes me think it failed to navigate back to wezterm.

[numToStr]

In navigator, we are only using the wezterm cli to execute commands so It could be a bug within wezterm, I am not sure as I don't use wezterm.

[ir-ae]

So I experimented a bit more with it and have found that its only using a keymap that fails. Calling :NavigatorRight or even :!wezterm cli activate-pane-direction Right both work as expected. I tried disabling the Wezterm keymaps to see if they were conflicting somehow but it didn't change anything. This leads me to think that it can't be Wezterm as the only thing exhibiting strange behavior is the Neovim keymaps which I am using exactly as in the README

[numToStr]

Hmmmm... that's really interesting. If the keymap is the culprit then maybe we need to provide some option to keymap, that I am not aware of, or this is a bug in neovim itself 😅.

[ir-ae]

Okay I think I found the issue... when calling wezterm cli activate-pane-direction Right; sleep 5 from my shell it moves the focused pane immediately but takes 5 seconds to update the gui.

From reading the Neovim docs: io.popopen starts the program in a seperate process and :!command runs in a non-interactive shell which both exit after the command is run. I don't know how vim keymaps work but I guess it's doing something Wezterm doesn't detect even though its calling the same :NavigatorRight command that works when typing it out.

I really don't know enough about terminal escape sequences to say if this is an okay way or not but... one way of fixing it without any noticeable side effects seems to be putting io.write("^F") (with ^F being the escape sequence for ACK) between line 48 and the return here:

Navigator.nvim/lua/Navigator/mux/wezterm.lua

Lines 44 to 51 in a440fea

	---Switch pane in wezterm
	---@param direction Direction See |navigator.api.Direction|
	---@return WezTerm
	function WezTerm:navigate(direction)
	self.execute(string.format('activate-pane-direction %s', self.direction[direction]))
	return self
	end

There is almost certainly some better way to get Wezterm to redraw itself (either from within Neovim or from in the provided Wezterm snippet) but I'm just figuring this stuff out as I go. I mostly just wanted to prove that it is technically possible to fix from within Neovim

[numToStr]

From reading the Neovim docs: io.popopen

I also tried ':h uv.spawn()' but facing the same issue 😅.

I really don't know enough about terminal escape sequences to say if this is an okay way or not but... one way of fixing it without any noticeable side effects seems to be putting io.write("^F") (with ^F being the escape sequence for ACK) between line 48 and the return here:

Yes, this seems fairly reasonable. If this works across platforms i.e., windows and unix without any side effects then it would be worth it.

---

@marty-oehme What do you think about the issue and the solution? Did you ever faced this issue while implementing the wezterm integration?

[ir-ae]

Actually I don't know how I missed this before, but io.writeing any escape sequence I've tried changes the text cell that the cursor is on to a corresponding ascii character e.g. (^F results in a ♠). I can't find any other way to get it to update though.

[marty-oehme]

Mh, this is indeed very interesting. @ir-ae I tried your sleep snippet and I have the same behavior: takes 5 secods to highlight the other pane but I can write immediately and when I do it immediately highlights.

However, when switching away from nvim the highlight update always happens immediately for me.
Which OS are you using that it does not work correctly on?

My best guess for now would be that the issue appears in the wezterm snippet call to pass through the keys to send to the window, thus to neovim which immediately passes it back. Since the issue does happen for you when manually invoking :NavigatorRight.

I am unfortunately a bit strapped for time currently, but when I find some I'll take a look to see if we could manually update the wezterm render; or maybe something will develop in your raised issue - thanks for raising it!

[ir-ae]

Which OS are you using that it does not work correctly on?

I ran into this using Windows but I've also tested it on my Linux laptop and its the same behaviour

My best guess for now would be that the issue appears in the wezterm snippet call to pass through the keys to send to the window, thus to neovim which immediately passes it back. Since the issue does happen for you when manually invoking :NavigatorRight.

Actually the interesting thing is :NavigatorRight does work for me... its just calling it from a keymap that doesn't.

Okay so literally as I typed that out I realized the difference. The keymaps use <CMD> which basically executes invisibly... whereas calling it manually uses : which redraws the bottom row of Neovim after the command executes. The redraw in Neovim causes Wezterm to redraw.

And after some quick testing changing the keymap to :NavigatorRight<cr> actually makes it work. I could've swore I tried that earlier but I guess not.

[ir-ae]

Changing the keymap to use : is undesirable because using a plugin that changes your cmd line, for example Noice, can be very visually distracting compared to <CMD>. Also a bad solution is just calling print("moved pane") or something in the plugin's Wezterm:navigate function. I tried :redraw! but it didn't seem to work.

I'm not sure if there is a good solution on the plugin side of things. This really just seems like a Wezterm issue. I'll leave this open for now in case you have a better fix or you want to put a note in the README about the issue but otherwise feel free to close this.

[numToStr]

Thanks for the investigation. Yes, let just leave this issue open for tracking and wait for the explanation from the wezterm team.

[ir-ae]

This is now fixed in Wezterm. wez/wezterm#3303