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.
I added this originally to see if the templating was working correctly.
With the recent changes to make it a cask, it's now much longer and
obscures some of the other more valuable output, so remove it.
Adding unix part of std redirect code. Also modifying existing changes based on feedback from the initial PR.
More changes based on feedback from PR.
Non linux unix OS's forced to use dup2 instead of dup3
Avoiding disposal issues with fd.
Small bit of refactoring plus some more ammendments based on more PR feedback.
Non linux compile issue fix.
Adding return
Another fix
Another fix
More amendments
fmt correction
closes: https://github.com/wez/wezterm/pull/816
closes: https://github.com/wez/wezterm/pull/788
closes: https://github.com/wez/wezterm/issues/786
This commit adds a slant to *scalable* (not bitmap!) fonts whose
originating font attributes requested italics but for for which
the resolved face is not italic.
refs: #815
This kill/wait was added to workaround fish being weird on macos.
This is accidentally exponential as the pty layer already loops,
so we don't need to also loop here.
refs: https://github.com/wez/wezterm/issues/774
