attach neovim resize issue

[neurosnap]

Hello! First, thanks for making such a useful tool! It's helping me remove my dependency on tmux.

What happened
Please explain what went wrong with your usage of shpool.

I have two computers that I use to ssh into my headless dev box running neovim. If I attach 1 client to shpool+neovim, everything works fine. Eventually I detach by closing my laptop lid

When I move to my other computer and try to reattach to neovim, it looks like the window size for neovim does not get readjusted and there's a big empty box at the bottom of my screen.

What I expected to happen
Please explain what you think should have happened instead.

When I dettach and reattach from shpool+neovim, I expect neovim to resize to match my window size.

I've tried change the size of my terminal window, sending SIGWINCH events, but nothing seems to work.

I'm also using fish if that makes a difference.

To Reproduce
Steps to reproduce the behavior:

• Create session with fish then neovim (computer a)
• Detach (computer a)
• Reattach (computer b)
• neovim does not scale to match new window size

Version info
Run shpool version and paste the output here

v0.9.1

Logs
Run journalctl --output cat --user -u shpool to pull logs related to shpool, then attach the file
to this issue. You may need to trim the output with tail.

I can provide these if they would be helpful.

[ethanpailes]

Are you using the same terminal emulator on the two different machines, or are they different? One problem that shpool has is that it sets all the environment vars on shell startup, and they can't really be updated after the fact. If you have two different TERM values for two different terminals, that may be a factor (since neovim could be determining which control codes to use based on that TERM value).

[neurosnap]

Hi, thanks for taking the time to look at this issue!

TERM=xterm-256color for both terminal emulators.

• computer A uses foot
• computer B uses ghostty

I just reattached using computer A and neovim is sized correctly. I'll also mention that every other shpool session I have works perfectly. It's just neovim that is a little jank. If I knew how to debug I would gladly continue to investigate but I don't exactly know where to start.

[ethanpailes]

Hmm, despite the different terminal emulators the fact that they have the same TERM value means that's probably not what is going on. (I'm assuming that neovim works fine within a shpool session you started from computer B, which would let us rule out anything inherent to ghosttty on its own).

I'm curious to see your shpool daemon logs. They shouldn't have anything sensative as long as you haven't cranked the logging up to trace mode (which logs your terminal input and output), but it's still probably a good idea to glance over them to confirm before posting them publically. If you want to avoid posting publicly you could send them to my last name at google dot com.

[rockorager]

I have a theory.

Neovim supports in-band-resize events. Both ghostty and foot also support this. When neovim opens, it queries the terminal for support and enables the mode. When the mode is enabled, the terminal sends resize events via escape codes. It also still sends SIGWINCH events - however neovim might decide not to listen to those when it is getting events from the escape sequence stream.

So for this issue: if neovim opens in foot and turns on the mode, and then doesn't listen to sigwinch all is good.

Then you detach and exit the terminal.

Then you attach with a different terminal. Neovim is still in this mode - the terminal is not. Neovim wants to get the sequences in the stream, but the terminal doesn't know to do it.

@gpanders may be able to confirm this on the neovim side.

[gpanders]

That is exactly correct. Neovim disables the SIGWINCH listener when in-band resize events are enabled.

We could leave it enabled, though if we do that then I think the resize events become redundant?

[ethanpailes]

If it is easy to just keep listening for SIGWINCH events within neovim, it would be great if you could do that.

The principled fix would be for shpool to track the terminal state and then try to restore the client terminal to the expected state during reattach. We have this same issue for kitty escape sequences. Fixing the problem is hard though, and probably requires a new implementation of the virtual terminal (which we currently use the pretty janky shpool_vt100 crate for).

[ethanpailes]

#44 is some relevant context here

[neurosnap]

Thanks, @ethanpailes that makes sense.

@gpanders is there any way to send the terminal character codes to re-enable in-band resize events from within neovim? This would allow me to reattach and then send the codes to renable it in my new term as a workaround.

[gpanders]

@gpanders is there any way to send the terminal character codes to re-enable in-band resize events from within neovim?

This should do it:

io.stdout:write('\027[?2048h')

[neurosnap]

@gpanders I confirmed that running that command :lua io.stdout:write('\027[?2048h') re-enabled in-band resizing events and properly resized nvim, thanks!

[scosu]

Thanks, the command works for me as well. My setup is kitty -> fish -> ssh -> shpool -> fish -> nvim.
After a long suspend/resume shpool is reattached and the nvim resize is broken. Executing the command fixes that.

[ethanpailes]

I added this workaround to the wiki until we have a real fix.

I realized an easier fix than fully tracking terminal state and generating one of these in-band resizes would be to intercept the capability query that asks the terminal if it supports these resizes and replace the "yes I support them" response with "no sorry." Then SIGWINCH will continue to work as expected.

[gpanders]

@neurosnap When you run into this issue does suspending Neovim (with Ctrl-Z or :suspend) and then resuming it (fg from your shell) resolve it?

It should because Neovim re-queries the capability on resume and will re-enable the mode with the terminal if it detects that it's supported.

This won't work if you are re-attaching with a terminal that doesn't support the in-band resize events though, because we do not re-enable the SIGWINCH handler if the terminal doesn't support the events. We often assume in the Neovim TUI code that Neovim is always talking to the same terminal, so I'm not surprised that this scenario is causing issues!

[neurosnap]

@gpanders Confirmed, Ctrl+Z + fg did restore the terminal size properly!