While debugging on windows earlier today I saw that we were
blocked on this wait on the main thread. For whatever reason,
that only blocks in practice on Windows; I suspect that this is
due to a timing issue on windows where the server side takes
longer to respond than it does on posix.
The root cause and secondary effect were a little surprising: the mux
pub/sub notification pipe filled up and because the mux notify routine
uses `retain` with the success of the send as a predicate it meant that
the full pipe resulted in the muxer killing that end of the subscriber
and that in turn made the ClientSession loop fail when it was
dispatching a notify on the other end, which terminated the loop and
disconnected the client.
Now, with this fixed, we have a flow control problem and the terminal
will remain busy with ctrl-c not being effective in the mux session.
This was an accidental casualty of some recent refactoring;
we need to clear the selection range when lines that intersect
with it are changed, so that's what this does.
Fixes: https://github.com/wez/wezterm/issues/118
Matching against the current dir when it includes a host and a
path seems like a handy way to automate selecting appropriate
theme/color/profile settings, so I'd like to make sure that
we have the full URL content available for that.
Refs: https://github.com/wez/wezterm/issues/115
Refs: https://github.com/wez/wezterm/issues/117
I'll write up more comprehensive docs once CI has proven that
the color schemes are packaged correctly.
The gist of it is that you can now specify:
```
color_scheme = "Batman"
```
to specify the default color palette.
The name corresponds to one of the color schemes from the
`assets/colors` directory. That directory is packaged and installed by
the CI deployment script, but we're also able to load them from the
source dir if you're running from in the wezterm source tree.
You can see previews of the various schemes here:
<https://iterm2colorschemes.com/>
In addition to loading from those that path, wezterm will search:
* In the `config` dir that is a sibling to `wezterm.exe` on windows
(not yet tested!)
* The directories specified in your `color_scheme_dirs` config setting
(multiple paths can be specified)
* You may also define schemes directly inline in your config file
using syntax like this:
```
[color_schemes."My Name"]
foreground = "#4a4543"
background = "#f7f7f7"
```
These visual artifacts seemed to affect everything other than Wayland
and were a bit annoying. The manifestation was that the cursor outline
box might have an extra line of another color on one or more of the
borders; whether it did or not seemed dependent on a combination of the
position of the cursor and the pixel width/height of the overall window.
This commit sets the texture sampler to prefer not to interpolate/merge
the value if it is between pixels and instead take the nearest texel.
Resizes can transiently result in lines whose length doesn't
match the vertex buffer width. If that happens, we probably
still derive value from painting the remaining lines, so allow
that to continue rather than blowing up the render.
This fixes a problem where a closed tab would linger until a subsequent
input event. The issue was that the layer at which we detect the tab
closure didn't have a way to signal the gui layer to repaint.
This commit adds an invalidated flag to the mux window object that is
updated when structural changes occur to its tabs; added, deleted,
activated and so on.
We check that flag in our periodic function in the gui layer and then
trigger a gui level invalidation if we see that it is set.
Record a notion of the state of the invalidations that we've sent
to the client so that we can skip sending updates if nothing has
changed since the last push.
It was possible to exhaust the number of fds on the server by
opening a vertical vim split and aggressively sliding it left
and right.
This commit allows the produce side to clone an arbitrary number
of senders without using up file descriptors.
Still not perfect; there's a window invalidation missing from
the mux somewhere on higher latency connections that gets
resolved just by moving the mouse :-/
There was an issue where we'd get stuck with a placeholder empty
line in a couple of rows when running `ls -l /etc` and scrolling
backwards. The damage was actually done during execution of the
ls command and was because we'd get confused about the state of
some of the line entries.
This diff introduces a proper state enum for them and defines
state transitions more rigorously.
I noticed the mux was running hot when idle and observed that it was
repeatedly fetching the line with the cursor.
Extract the logic into a helper function that is called from both
of the places that fetch and put lines; noticed that we were not
consistently processing hyperlinks.
When running the mux server we don't have an active window::Connection
so we can't use its spawn_task function. This little helper runs
the futures on the appropriate Tasks instance.
We can't use a trait method for this because traits abhor generic
parameter types.
The client side will limit how many rows it decides to speculatively
prefetch and defer to the lines requested by the renderer once we
exceed a certain number of fetch requests per second.
On the server side, we weren't actually coalescing individual tab
output events together; this commit restructures the end of the
appropriate loop block to make that effective.
This avoids a hang on startup if you're using an ssh multiplexer
connection and haven't already registered your ssh key and need
to perform password authentication.
The last config reload time didn't seem to stick in the periodic timer
callback.
Need to investigate that further, and also see if the blink paint
time is similarly impacted.
