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

Open
opened 9 months ago by dnkl · 4 comments
dnkl commented 9 months ago
Owner

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.

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.
dnkl changed title from Add an to Add a 'wait-for-mapped' option 9 months ago
dnkl added the
enhancement
label 9 months ago
Collaborator

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

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

> ... buggy applications that don't use SIGWINCH properly @dnkl Do you have a specific example of this, for reference purposes?
Poster
Owner

@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 issuing (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).

@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 issuing (like described in https://codeberg.org/dnkl/foot/issues/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).
Collaborator

... my guess is applications that exhibit sizing issuing (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 when I asked the question.

I looked at the SIGWINCH handler in ncmpcpp and even a quick glance shows some other issues:

  • It uses the obsolete (and basically broken; in the context of POSIX) signal() function instead of sigaction()
  • It uses volatile bool instead of volatile sig_atomic_t, which kind of defeats the point of that approach to signal handling

I also looked at the vim signal handling code briefly, but it's harder to figure out exactly what's happening in that case, since it's such a sprawling codebase, with ifdefs everywhere.

Possibly relevant issues:

> ... my guess is applications that exhibit sizing issuing (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 when I asked the question. I looked at the `SIGWINCH` handler in `ncmpcpp` and even a quick glance shows some other issues: * It [uses](https://github.com/ncmpcpp/ncmpcpp/blob/40e4f98ee896ea10967eb1c4323bb718331eabea/src/ncmpcpp.cpp#L112) the obsolete (and basically broken; in the context of POSIX) `signal()` function instead of `sigaction()` * It [uses](https://github.com/ncmpcpp/ncmpcpp/blob/40e4f98ee896ea10967eb1c4323bb718331eabea/src/ncmpcpp.cpp#L59) `volatile bool` instead of `volatile sig_atomic_t`, which kind of defeats the point of that approach to signal handling I also looked at the vim signal handling code briefly, but it's harder to figure out exactly what's happening in that case, since it's such a sprawling codebase, with `ifdef`s everywhere. Possibly relevant 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.

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.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.