We need to build in release mode so targets are cacheable.
GH has a limit of 400MB per cache blob and we're at 750MB with
the debug build. Slim it down a bit.
The cache wants to hash the Cargo.lock file so I've removed that
from the ignore file and added it to the repo. This might cause
an error for users checking out the repo after this change is
pushed; removing the local Cargo.lock should resolve that.
The cursor should only start blinking when its been sitting in once place;
a moving cursor should always be visible. Rather than making the cursor blink
relative to the creation time of the window, track its position, and use the
last time it moved as the blinking timebase.
Fixes https://github.com/wez/wezterm/issues/83
This is a bit of a speculative change to see if it helps with
refs: https://github.com/wez/wezterm/issues/82
I have sometimes seen my scrollbar have a color that I didn't
choose and ISTR having some issues in the past when updating
the quads if I didn't set all of the fields of the vertex
to a better defined value.
These are used in the default Fedora 31 bash profile, so it seems
worth handling even if they are a bit amgiguously defined.
Closes: https://github.com/wez/wezterm/issues/86
A while back I moved the clipboard related processing mostly out
of the term processing code, but since I mostly use the keyboard
for pasting, I'd overlooked the middle mouse button paste flow.
This is problematic because fetching the clipboard requires a
degree of inter process communication and needs the event loop
to be pumped. Since the terminal callbacks are dispatched from
an event loop callback, attempting to block on the clipboard
future causes a deadlock.
This commit resolves that issue by anticipating that we'll need
the clipboard contents for the majority of middle mouse button
clicks and scheduling a fetch and cache ahead of passing that
event down to the terminal layer.
Why don't we simply use the same technique as the Paste key
assignment? If the terminal is currently using SGR mouse
tracking mode then the application on the other end of the
pty will want the raw button press. Our layering doesn't
allow for passing up the concept of whether a middle button
does paste or sends the raw event.
tricksy!
Refs: https://github.com/wez/wezterm/issues/87
@jsgf mentioned this to me, and since I've started running "proper"
wayland gnome-shell/mutter on my pixelbook go, I'm seeing it too.
The issue is that the alpha values are potentially <1.0 when they
are committed to the frame buffer and the mutter compositor is
faithfully blending wezterm with the window behind it, leading to
weird looking effects such as varying brightness of text, or for
cases where the window behind wezterm is bright white, a halo
effect that makes the text less sharp.
This commit addresses this issue by asking glium to ask opengl to
set the destination alpha to 1.0 in the final draw stage.
I noticed this for small enough sizes of Fira Code the border width
for the cursor would round to zero, and then looking at eg: `man ls`,
the underlined portions had no underline.
Ensure that the underline size is at least 1 pixel.
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!
* harfbuzz includes some ttf fixtures.
* libpng has some test images
* the wezterm web page has some movie files(!)
None of these are required to be in the source tarball, so strip them
out to save ~40MB and bring the tarball down to <5MB.
Refs: https://github.com/wez/wezterm/issues/46
The offset math around the scroll thumb made me uncomfortable
so this commit introduces a struct to keep track of the vertex
indices and make it easier to recall them later.
@fanzeyi ran into part of this issue when using multiplexing;
tabs from a remote domain always used the default color scheme
rather than the local configuration file color scheme.
Another variation on this is that making changes to the `[colors]`
section of the config only impacts tabs created after the change
was loaded, rather than updating the running tabs.
The root of this was that each terminal was keeping its own
copy of the palette that was updated at creation time to reflect
the config file. Relatively recently I introduced a new trait
to allow the terminal state to reach out and obtain configuration
from another source.
This commit connects the terminal configuration layer to the
configuration file directly.
The color schemes are now pulled directly from the configuration
file, except in the case where a dynamic color scheme has been
applied: using escape sequences to change the colors causes
the palette to be forked away from the configuration file.
There's still a low pri TODO around this space: if we're connected
to a remote domain and someone uses dynamic color scheme escapes,
should we reflect those locally? If so then we'll need to build
some plumbing to transport the palette to/from the remote system.
Closes: https://github.com/wez/wezterm/pull/60
