The root cause of this was a bit of a hack to ensure that we didn't
prematurely shut down while waiting for ssh sessions.
Introduce an Activity token that will extend the lifetime of the
event loop even if there are no windows present.
This cleans things up both on macos the application would linger in
the application switcher until you had tabbed away and back again,
and also for the null frontend which had grown a less gross hack.
Rust maintains the borrow from the match expression for the lifetime of
the match blocks, even though there is no relationship between the
value in scope in the blocks :-/
Having separate statements makes things happier.
Selection got accidentally moved to be scoped by window during
the remodel. This commit moves it to the per tab state.
refs: https://github.com/wez/wezterm/issues/89
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.
We would leave a copy of the alt screen lines at the top of the
scrollback.
This commit ensures that those lines are marked dirty and that
the dirty bits are propagated to the client to invalidate its cache.
We were ignoring the title returned by list tabs and would subsequently
only pick up the title after a later update.
This passes the title in at construction.
The issue is that when we start the proxy mode up, we haven't set
up a frontend, and the ssh client wants to kick off a non-essential
task via the executor.
This commit starts up a null frontend in proxy mode so that that
machinery is present.
Then, because we don't register any tabs with the mux, we need to
adjust the behavior of the null frontend to not terminate when
the mux has no tabs.
It's a little gross.
This mostly works, but has a cache invalidation issue wrt.
passing invalidated rows from the server to the client...
sometimes.
However, scrollback is cached on demand and selection works.
Use StableRowIndex to implement tracking the viewport in the gui layer.
This resolves an issue where a busy terminal would continue to scroll
through the scrollback when you were paging backwards and look weird.
There's still some cleanup though:
- This breaks the selection ui
- the cursor position is wrong when scrolling back
- shift-pageup/pagedown need to be processed in the gui layer
Refs: https://github.com/wez/wezterm/issues/106
It's not really moved, but rather duplicated there; we still have
fallback logic in terminalstate.rs that processes the equivalent
action, but adding the logic to the gui layer means that we can
process it in terms of the Tab and Renderable interfaces.
refs: https://github.com/wez/wezterm/issues/106
When the scrollbar is disabled we still create a quad for it, and that
quad stretches to the window height. It is left with undefined texture
and could be either partially or totally transparent and lead to weird
effects like it appearing as though the titlebar was too wide for the
window, or by dimming the RHS of the window when toggling the scroll
bar on and off a few times.
This commit ensures that we set a well defined size and color when
the scroll bar is disabled, and seems to improve things for me.
Refs: https://github.com/wez/wezterm/issues/103
This commit adds the ability to change the relative or absolute
position of a tab within its containing window through the
use of a key assignment.
We include a default assignment of CTRL+SHIFT+PageUp for moving
left and CTRL+SHIFT+PageDown for moving right.
Closes: https://github.com/wez/wezterm/issues/84
If the cells refer to the same object instance (rather than equivalent
instances), then we treat them as part of the same highlight.
Refs: https://github.com/wez/wezterm/issues/94
Now that we can track focus changes, we can eliminate an annoyance:
clicking in the window to focus it would cause a click event to
be passed to the terminal and clear the selection.
This commit will swallow button events that occur within 200ms
of the focus being gained by the window.
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.
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.
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
This commit:
* Removes the ability to drag the window by the tab bar. I added
that in anticipation of needing to do custom title bar dragging
with Wayland, but it turned out both to be not required and not
possible to drag windows around in that way.
* Replaces the drag logic with dragging the scrollbar thumb
* Clicking above the scrollbar thumb is equivalent to page up
* Clicking below the scrollbar thumb is equivalent to page down
This commit adds a scrollbar that shows the scroll position but
that does not currently allow dragging to scroll.
The scrollbar occupies the right hand side window padding.
The width of the scrollbar can be set by explicitly configuring
`window_padding.right`. If the right padding is set to 0 (which
is its default value), and the scroll bar is enabled then the cell
width will be used for the right padding value instead.
The scrollbar can be enabled/disabled via this config setting:
```
enable_scroll_bar = true
```
Its color by this:
```
[colors]
scrollbar_thumb = "#444444"
```
(Note that color palette config will be reloaded when the config
file is changed, but you'll need to spawn a new tab/window to
see the effects because we cannot assume that a config reload should
always replace a potentially dynamically adjusted color scheme in
a tab).
This commit adds some plumbing for describing the cursor shape
(block, line, blinking etc) and visibility, and feeds that through
the mux and render layers.
The renderer now knows to omit the cursor when it is not visible.
@jsgf suggested that it would be nice to have a degree of padding
around the terminal cells. This commit adds some plumbing for this;
```
[window_padding]
left = 10
top = 0
right = 10
bottom = 0
```
The left and top padding are used top compute the top-left coordinates
of the terminal cells. The right and bottom padding act as minimum
values; the actual padding used may be larger depending on the size
of the window and the number of cells that fit the available space.
top padding > 0 and the tab bar needs some work.
