Adds the ability to specify `--font-shaper Allsorts` and use that
for metrics and shaping.
It is sufficient to expand things like ligatures, but there's something
slightly off about how the metrics are computed and they differ slightly
from the freetype renderer, which leads to some artifacts when rendering
with opengl.
One of my tests is to `grep message src/main.rs` to pull out the line
that has a selection of emoji. The heart emoji is missing from that
line currently.
Refs: https://github.com/wez/wezterm/issues/66
I noticed that we were relatively undersized for newly created
windows; there were two problems:
1. We weren't propagating the old rows and cols counts through
to the speculative resize.
2. The speculative resize wasn't implemented on wayland, and
needs a surprising amout of work to actually make the resize
take effect.
This was honestly a PITA because of its complexity. The `clipboard`
crate (now dropped as a dep) didn't support wayland, so I looked at
the `smithay-clipboard` crate, which caused all of my input to become
laggy just by enabling it--even without actually copying or pasting!
Both of those crates try to hide a number of details of working with
the clipboard from the embedding application, but that works against
our window crate implementation, so I decided to integrate it into
the window crate using Futures so that the underlying IPC timing and
potential for the peer to flake out are not completely hidden.
This first commit removes the SystemClipboard type from wezterm
and instead bridges the window crate clipboard to the term crate
Clipboard concept.
The clipboard must be associated with a window in order to function
at all on Wayland, to we place the get/set operations in WindowOps.
This commit effectively breaks the keyboard on the other window
environments; will fix those up in follow on commits.
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.
The future won't ever complete if you don't connect the waker
from the context!
Prove this out by making the windowops functions async and
verifying them in the async example
I introduced this issue with the recent rate limiting changes. If we
generated sufficient events to fill the pipe buffer and trigger an
EAGAIN on the write side of the pipe, we'd end up in a state where epoll
would continually wake us up to deal with it, but because we gated
reading from the pipe on having entries in the queue we could decide
that there was nothing to do and leave the pipe unread.
This commit adjusts things so that we always try to read some data from
it.
This is OK because we're using the pipe to knock the main thread out of
a sleep rather than as the definitive count of events.
I'm seeing occasional 100% cpu usage on my linux system and I'm
not sure if its just because I'm running a stale binary.
I added this (commented out in this commit, but live on my local
system) debug print to help understand it.
