I don't think font-kit has enough data available for to make things
work the way we're used to. In addition, the implementation of
the loader for core text has a lot of TODO's.
The state of the FontKit variant is that it basically renders glyphs
and they are aligned to the same baseline, but both the vert and
horz metrics are off; for example, `-` doesn't render. The glyphs
are also under-sized.
This is another option to help with the portable wezterm on a flash
drive use case.
When the font system is set to FontKitAndFreeType, the set of
directories specified by the `font_dirs` configuration option will
be scanned for fonts and used as a source for fonts.
In addition, any relative paths in the the `font_dirs` list will
be expanded relative to the configuration file path.
That allows deploying the following set of files to the root of
a flash drive:
* wezterm.exe
* wezterm.toml
* fonts/myfont.ttf
and with this config snippet:
```
font_system = "FontKitAndFreeType"
font_dir = ["fonts"]
```
wezterm will now consider myfont.ttf when loading fonts.
Refs: https://github.com/wez/wezterm/issues/73
This commit adds two new font system variants that are currently
implemented only on Windows:
* FontKit - uses fontkit both for font discovery and rasterizing
* FontKitAndFreeType - uses fontkit for font discovery but freetype
for rasterizing
To a certain extent, FontKitAndFreeType obsoletes FontLoaderAndFreeType
and I'll be looking at removing it once I can test the build on macOS.
The FontKit impl has bad metrics and also crashes during shaping
on Windows, so it's not ready to be used by default.
The NoticeXXX variants are emitted at the trigger point, but
we should wait for the debounced XXX variants instead. We
were doing this for write but not for delete. This should
improve the chances that we'll pick up a new version of a
config file.
Even with setting this, I'm 0 for 4 different systems in having the
notifications actually stay on the screen until dismissed.
This was successful at displaying a notification on the pixelbook
desktop though, so that's 1/3 linux systems that have had success.
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.
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!
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
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've found that 10_000/s strikes a reasonable balance between
output speed and the ability to interrupt the output.
Refs: https://github.com/wez/wezterm/issues/65
We need to chunk the data that we read from the child otherwise
we may potentially try to admit more data in a single action
than the ratelimiter will ever allow (eg: if we read 4k of data
and the limit is 100 bytes per second, we can never send that
4k of data in a single write).
Our handling of that situation was not good: we'd panic and kill
the background thread that was reading the data, but the rest
of the app was still running.
This commit upgrades to the most recent rate limiter crate
and performs explicit chunking of the output so that we
behave more sanely.
Refs: https://github.com/wez/wezterm/issues/65
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.
previously, if you had defined a list of fonts, we'd show a todo error
and ignore everything but the first entry on linux.
We now parse the list into a set of fontconfig patterns and compose
them together, giving prefernce to the explicitly listed fonts.
(details in the comments in the code).
This allows color emoji to render for user defined fonts without
forcing the user to muck around in fontconfig config.
Added Noto Color Emoji to the fallback; this is used in our
ssh password prompting UI when available.
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
refs https://github.com/wez/wezterm/issues/34
A number of key bindings that used super on macos are also
aliased with bindings that use CTRL+SHIFT for improved
compat with windows.
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.
I noticed while scrolling `emoji-test.txt` that some of the combined
emoji sequences rendered very poorly. This was due to the unicode
width being reported as up to 4 in some cases.
Digging into it, I discovered that the unicode width crate uses a
standard calculation that doesn't take emoji combination sequences
into account (see https://github.com/unicode-rs/unicode-width/issues/4).
This commit takes a dep on the xi-unicode crate as a lightweight way
to gain access to emoji tables and test whether a given grapheme is
part of a combining sequence of emoji.
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
We handle this with a temporary buffer for the upload, which is
a little gross but avoids leaking that implementation aspect
out to the rest of the code.
This is still a bit rough because the terminal parser doesn't
understand the pixel sizes, so it relies on the hard coded
cell dimensions being accurate.
