Expand on the changes in 3f6ff534d3,
this makes them more general and so that they can be used on unix
systems.
That in turn helps to tackle https://github.com/wez/wezterm/issues/839,
wherein `sleep 300 & disown ; exit` would linger until EOF is detected,
rather than triggering as soon as the child process terminated.
For whatever reason, that would only manifest on linux (and not macos).
Same vein as 8931afba5cee07ab12990f06c2ff34d6f8426b19; the auth
window could sometimes get stuck until an input event was sent
to it.
Wire up a mux event so that the window can close itself.
When the client connected to an empty remote mux, it would allocate an
empty window and then spawn a new tab into it.
Meanwhile, the authentication window would close and trigger a prune of
all empty windows, causing the in-flight spawn to fail because its
destination window was removed.
This commit defers window pruning while Activity is in progress;
the MuxWindowBuilder has an associated Activity count.
neovim doesn't like it when multiple drag events with the same
coordinates are received; it appears to treat that as though
the mouse button was double clicked.
This commit teaches the mouse report encoding to suppress multiple
drag events in succession that have the same payload.
refs: https://github.com/wez/wezterm/discussions/823
Possibly related to:
https://github.com/wez/wezterm/issues/783
However, this is more obviously required when scrolling back either
via mouse wheel or a key assignment: the download completes but
we need to then force an invalidation for it to be applied in
the gui.
This looks like a honest typo from when panes were introduced!
We were passing the tab id rather than the pane id when specifying
the target of a split.
likely fix for this issue:
refs: https://github.com/wez/wezterm/issues/781
Use a similar hsv transformation to that used to dim inactive panes
instead of the treatment that made the black look grey, which felt
like a flash instead of a dim.
in https://github.com/wez/wezterm/issues/767 CTRL-Tab was getting
incorrectly normalized to CTRL-i; that normalization is valid (Tab is
actually equivalent to CTRL-i as far as unix terminals are concerned)
but unwanted at this layer.
I suspect that this change will come back to haunt me in the future,
as keyboard input is a bit of a zoo.
in the same vein as d657721163, the
increased idle loop means we need to be careful not to suppress
invalidation events.
In this case, overlays aren't from the window in the mux model,
so we'd ignore invalidations for those.
While looking at this I realized that we'd also do the same
for output being emitted in panes that were not the active pane,
so tidy that up.
in the same vein as d657721163
this commit introduces more assertive signalling from the remote
mux when a pane is closed so that the client can update.
Similar to 3f6ff534d3, we need to
tickle the mux to detect when the session terminates.
In this case we can relatively simply schedule an async wait without
spawning an additional thread.
Since removing the regular periodic background tasks, we're now
prone to not noticing child processes exiting.
This commit explicictly schedules a thread to do that on Windows
so that we can close a tab as soon as it exits.
At the bottom of https://github.com/wez/wezterm/issues/815 is some
discussion about an apparent hang.
Let's make the self pipe writing a bit more robust and log to see
if that might be related.
