Add a 'wait-for-mapped' option #453

Add a --wait-for-mapped command line and configuration option. When used, defer spawning the client application until the window has been mapped.

This ensures the client application sees the final window size immediately.

I.e. this is a workaround for buggy applications that don't use SIGWINCH properly.

... buggy applications that don't use SIGWINCH properly

@dnkl Do you have a specific example of this, for reference purposes?

@craigbarnes I don't have any code pointers, if that's what you're asking for. I was perhaps expressing myself somewhat sloppy; my guess is applications that exhibit sizing issues (like described in #723) are racy, and request the initial size before registering their SIGWINCH handler. But it's just a guess.

Others purposely ignores some of the initial resize events, like neovim (https://github.com/neovim/neovim/issues/11330)

I don't usually start applications directly in a new terminal window, and thus I don't really notice these issues. With that said, I have seen it it neovim and top (not htop).

... my guess is applications that exhibit sizing issues (like described in #723) are racy, and request the initial size before registering their SIGWINCH handler.

Ah yeah, that makes sense. I was trying to imagine what kind of patterns might cause/worsen the problem, but my brain was running on empty.

Possibly relevant vim issues:

• https://github.com/vim/vim/issues/424
• https://github.com/tmux/tmux/issues/2064#issuecomment-597726208

Oh my - I've been running into this race for years :) I encounter it with some curses-like programs such as vim and neomutt. It's gotten to the point that I have shortcuts that spawn those programs in a terminal like:

foot bash -c "sleep 0.1; exec vim Documents/TODO.txt"

A flag to do this waiting for me would be absolutely wonderful.

I'm not sure how reliable it'll be, but I've just thrown this together as an alternative to sleep 0.1. It seems to reduce flickering somewhat and might help to avoid some resizing bugs in certain apps (but seemingly not mtm for some reason).

Depending on compositor, there may be multiple SIGWINCH signals at startup.

On Sway (at least older versions), there will be two. First, Sway asks us to size ourselves. This leads to a transition from the hardcoded 80x24 size to the by-user configured size (default: 700x500), and the first SIGWINCH. Then (after we've been mapped?) Sway tiles us, and we get a new size from Sway, leading to the second SIGWINCH.

Thus, waiting for the first SIGWINCH may not be enough, if the client application has racy check-size-then-register-sigwinch behavior.

@dnkl if it sounds wrong for Sway to send two signals, should we file a bug?

Also, if waiting for one signal may not be enough, what other mechanism do you think we could use? Does foot itself know when it has been mapped?

if it sounds wrong for Sway to send two signals, should we file a bug?

This is a known "feature", but don't know if a bug has been filed already or not. But yes, might make sense to do that.

Also, if waiting for one signal may not be enough, what other mechanism do you think we could use? Does foot itself know when it has been mapped?

Yes, we know when we've been mapped. Implementing the --wait-for-mapped option would, of course, need to know that (fixing this bug/feature shouldn't be that hard - might even be a first-easy-one for new contributors).

But, for those waiting for this to get implemented; it may not entirely solve the problem - if the second resize happens after we've been mapped (which I'm fairly sure is the case), then we might still trip up buggy clients. But with a lower probability than today.

if it sounds wrong for Sway to send two signals, should we file a bug?

This is a known "feature", but don't know if a bug has been filed already or not. But yes, might make sense to do that.

https://github.com/swaywm/sway/issues/2176

On Sway (at least older versions), there will be two. First, Sway asks us to size ourselves. This leads to a transition from the hardcoded 80x24 size to the by-user configured size (default: 700x500), and the first SIGWINCH. Then (after we've been mapped?) Sway tiles us, and we get a new size from Sway, leading to the second SIGWINCH.

@dnkl Thanks for the info. I think I saw you mention that in one of the other issues a while back, but it must have slipped my mind.

I've changed waitwinch to wait for the second SIGWINCH and it seems to prevent the mtm prompt issue now (under Sway). It's a bit of an over-engineered workaround compared to sleep 0.1, but it seems to lower the added startup latency to about (削除) 10ms (削除ここまで) 3ms.

For anyone interested, there's now a demo program in the waitwinch repo, which can be used to visually reproduce the kind of problem seen in buggy clients (e.g. #723).

Usage example:

git clone https://codeberg.org/craigbarnes/waitwinch.git
cd waitwinch
make
# Run demo program *without* waitwinch
foot --hold ./wwdemo
footclient --hold ./wwdemo
# Run demo program *with* waitwinch
foot --hold ./waitwinch -v ./wwdemo
footclient --hold ./waitwinch -v ./wwdemo

FWIW, I've been using shell = sh -c 'exec $(command -v waitwinch) ${SHELL:-sh}' (as mentioned here) in my foot.ini for quite a while now (as well as in some wrapper scripts) and I haven't had any issues. The measured latency shown by e.g. footclient waitwinch -v bash is about 3ms (as opposed to the 100ms you'd get for sleep 0.1).

@craigbarnes that's pretty cool! Though the colors are... hard to read, to say the least, with my color theme :)

foot-waitwinch-demo.png

@dnkl Thanks for the feedback! craigbarnes/waitwinch@7dc4d8e331 should hopefully make it a little more readable.

Better, thanks!