The wayland changes rendered clipboard handling for remote multiplexers
broken, and this commit makes it work again.
It removes the clipboard concept from the the TerminalHost and
keeps it separated as the term::Clipboard concept.
The muxer now has plumbing for passing the Clipboard to its idea
of Windows and Tabs and this is hooked up at window creation and
domain attach time.
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.
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
The defaults are pretty neutral. You can get a little more fancy
with something like this:
```
[colors.tab_bar]
background = "#0b0022"
[colors.tab_bar.active_tab]
bg_color = "#2b2042"
fg_color = "#c0c0c0"
[colors.tab_bar.inactive_tab]
bg_color = "#1b1032"
fg_color = "#808080"
[colors.tab_bar.inactive_tab_hover]
bg_color = "#3b3052"
fg_color = "#909090"
italic = true
```
This is a little ghetto feeling because we're just stealing the top
line from the terminal model, rather than rendering anything
particularly native, but it is relatively quick and easy to do,
and helps improve the feel when using wezterm on a chromebook
inside crostini; in that environment, the system doesn't render
any text in the window titlebars (WTF!?) so it is desirable
to show something to help navigate the UI.
The tab bar is off by default for now; we'll definitely want to
add options to configure at least the colors, and perhaps add
a keybinding to toggle it at runtime.
```
enable_tab_bar = true
```
While adding support for the tab bar, I found a couple of little
bugs relating to computing the number of rows and columns; one
was during resize where we'd use the prior size instead of
the current size. Another was during tab spawning where we'd use
a slightly different calculation to determine the size and end
up raising an error about being confused about the screen size.
previously we would only ever copy to the clipboard when the selection
was changed.
Now we respect the Copy keypress and have it re-copy the selection
into the clipboard.
This is a bit of a large commit because it needed some plumbing:
* Change mux creation to allow deferring associating any domains,
and to change the default domain later in the lifetime of the
program
* De-bounce the empty mux detection to allow for transient windows
during early startup
* Implement a bridge between the termwiz client Surface and the
frontend gui renderer so that we can render from termwiz to
the gui.
* Adjust the line editor logic so that the highlight_line method
can change the length of the output. This enables replacing
the input text with placeholders so that we can obscure password
input
On macos, allow sending eg: ALT-F as ALT-F rather than the composed
graphics character (ƒ) that is the default for that combination in
the macos IME.
This is controlled by a new config option which defaults to false
so that we have the expected terminal behavior by default.
This diff adds some plumbing to track the `raw_key` in the KeyEvent;
this is the key prior to composing or eg: mapping dead keys.
With that field in place, we can teach the termwindow layer to attempt
looking up that key mapping from the user defined key bindings.
If we get a match then we can stop further key processing.
The front-end was treating both \r and \n as Enter and passing
that through to the terminal.
To verify behavior, pay attention to your termios configuration:
```
$ stty -icrnl
$ od -c
<CTRL-J><CTRL-D>
0000000 \n
0000001
$ od -c
<CTRL-M><CTRL-D><Enter>
0000000 \r \n
0000002
```
Closes https://github.com/wez/wezterm/issues/56
