It's too fiddly to setup in practice, and literally no one has
expressed an interest in using it.
Removing it simplifies some upcoming work.
Closes: https://github.com/wez/wezterm/issues/35
* take a stab at fixing the windows CI to generate 64-bit
* use actions-rs/toolchain more broadly
* fixup target dir for deploy script
* cut over to the rust action for installing rust
This makes the input behavior consistent with posix: if SHIFT is held
and a letter key is pressed, make sure that we treat that as the ascii
uppercase version of that key and that the SHIFT modifier is cleared.
I got to the bottom of the hang on startup when trying to connect
to the multiplexer on windows and it was because of the change
in 367a44fb96 to try to drain the pollable
channel.
This mapped to ReadFile on windows which always tries to fill the buffer
even if it is a socket under the covers.
348421b010
teaches filedescriptor to use the recv/send if the filedescriptor is
really a socket and that resolves the hang.
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.
