The default values are 3 lines. With this change, scrolling speed now seems
similar to other programs like cmd.exe. Before this change it feels too slow.
Force using xcb-util 0.2.1 precisely because 0.2.2 pulls in a
conflicting major version of xcb (0.8 -> 0.9).
It's a non-trivial upgrade: the types around xkb are different
and features need to be specified in the manifest to enable compilation
of the things that we depend upon.
In addition, xkbdcommon, on which we depend, requires xcb 0.8 and
results in pulling in two conflicting versions of the crates.
It's a bit of a painful situation and will require some effort to
figure out how to upgrade the xcb dependency, when we're ready for that.
refs: https://github.com/meh/rust-xcb-util/issues/12
This is a pretty gross and coarse "smash them together" commit.
There is some redundancy between the two connection and window
impls that I'd like to unify later, but this lets us build with
support for both systems for now.
This isn't perfect, but is sufficient to allow using the IME to enter
eg: the heart emoji with cmd.exe.
We have some issues locating and rendering chinese characters that
make it difficult to prove/disprove that the IME is working 100%
because we just can't see the glyphs.
In addition, there appears to be something a bit wonky with conpty and
emoji. If we use eg: `wezterm ssh HOST` to log in to a remote system,
and use the IME to pick eg: the pig face emoji, this renders correctly.
In that scenario we don't use conpty at all.
The IME window is always placed in the top left corner of the window
at the moment, which isn't great, but is better than the system default
which is outside of the window. I need to introduce a way to set the
IME position in the window layer so that the front end gui can set it
to the current cursor position.
Earlier in the life of wezterm we had software rendering in src/xgfx.rs.
This is the bitmap portion of that code from rev
236960e1a8, tweaked slightly for more
recent changes to the palette crate.
