This isn't complete but begins the process of extracting
the embedding application configuration into a trait provided
by the application rather than passing the values in at
construction.
This allows the application to change configuration at
runtime.
The first option to handle this is the scrollback size.
I realized that I had set this to 10pts in my configs, and after running
with the default for a bit today, I agree with @chadaustin that we
should be smaller by default!
I keep holding shift while pressing space and seeing stuff get
undone in vim. Super annoying. I didn't see a good way to
teach applications about this via terminfo, so this is off
by default for now.
refs: https://github.com/wez/wezterm/issues/63
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.
It will pass the message text to the shell without proper quoting
which results in it running all sorts of garbage depending on
the message you're trying to display.
Very scary!
refs: https://github.com/jdm/tinyfiledialogs-rs/issues/19
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.
