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.
I noticed my trackpoint or touchpad reports a lot of < 120 (WHEEL_DELTA) events.
They shouldn't be ignored.
Also https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-mousewheel says:
> The wheel rotation will be a multiple of WHEEL_DELTA, which is set at 120.
> This is the threshold for action to be taken, and one such action (for
> example, scrolling one increment) should occur for each delta.
>
> The delta was set to 120 to allow Microsoft or other vendors to build
> finer-resolution wheels (a freely-rotating wheel with no notches) to send
> more messages per rotation, but with a smaller value in each message. To use
> this feature, you can either add the incoming delta values until WHEEL_DELTA
> is reached (so for a delta-rotation you get the same response), or scroll
> partial lines in response to the more frequent messages. You can also choose
> your scroll granularity and accumulate deltas until it is reached.
macos generates fractional distance values for the mouse wheel,
with one tick starting at 0.1. We were truncating this to a 0 row
move, which meant that you'd need to build up some acceleration to
move the rows when all you really wanted was a single tick.
This commit changes things so that we round up to at least 1.0 in this
situation.
The IME stuff on macos tends to swallow repeats for some keys.
Ugh. So this commit adds an option to disable the use of the IME.
Switching away from it effectively inverts the meanging of backspace
and delete (because our method is no longer called by the IME), so
we need to check for that and remap it. Ugh.
Ugh.
double clicks weren't registering correctly with the new selection
logic. Tell windows that we're doing all our own click counting
and simplify the logic.
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
On x11 we'd get just a single line per scroll wheel tick.
Contrast with Wayland where we get multiple.
This config change makes us feel more snappy by default on X11.
I'd like to make this configurable using the live configuration
infra, but we don't currently have a way for this crate to see
that config, so this just changes the default to be "better".
refs: https://github.com/wez/wezterm/issues/92
This reverts commit bfa8d0c207,
which proved not to be needed because it was already covered
by the `KeyboardEvent::Enter` and `KeyboardEvent::Leave` handling.
On a Fedora 31 system running Wayland I noticed that wezterm and
the compositor were running pretty hot on their respective CPU
cores.
It turned out that we had a lot of
[Refresh](https://docs.rs/smithay-client-toolkit/0.6.4/smithay_client_toolkit/window/enum.Event.html#variant.Refresh)
events being generated and consumed. We were treating this as needing
a full paint so we'd be effectively continually running the opengl
paint cycle over and over.
The docs for that event say that it is intended to refresh the client
decorations so let's focus it towards that instead. This does bring
the CPU usage back down to intended levels.
I believe this hot CPU usage to be compositor-dependent: this is the
first I've seen of it out of 4 different Wayland environments!
1f81a064ed added support for noticing
that the dpi scale was not 1 on startup, but the timing of this
signal was different between the opengl and software renderers.
When using the software renderer, we'd end up computing a scaling
change with a pre-change pixel size but adjusted by a post-post
scaling factor, and that effectively caused the window to halve
its size on startup.
This commit improves things by also tracking the dpi in our locally
stored dimensions.
@sunshowers mentioned to me that the window appeared blurry on a hidpi
display on startup, and was fixed by changing focus in a tiling window
manager.
I could replicate this using weston with scaling set to 2; the issue was
that the initial scale factor change event wasn't fully propagated and
bubbled up as a resize event to the terminal layer.
This commit taps into the dpi change event and forces it to be
interpreted as a window configuration change, resulting in more crisp
text.
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.
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
The compiler emitted `ud2` right around this code, effectively
breaking wezterm on startup.
In talking this through with @dtolnay, the definition of the
structs in the core_foundation crate makes it undefined behavior
to pass a null pointer to its fields, despite that being a valid
and documented way to use the struct.
This commit works around this by defining our own local versions
of the types and functions with the safe signature.
I'll follow up with the owners of the core_foundation crate
to submit an equivalent patch upstream.
we were running it immediately which is too soon: the empty
mux check would fire before some of the scheduled jobs would
have run and registered tabs/windows.
on mac the `Delete` key is really `Backspace` and should generate the
`BS` sequence.
`Fn-Delete` is equivalent to the `Delete` key on other keyboards and
should generate the `DEL` sequence.
BS maps to deleteBackward
DEL maps to deleteForward
heads up to @fanzeyi: this partially reverses 8c26b77057
