This was broken by b441be3ac9
For whatever reason, the breakage was only visible with the Iosveka
font on Windows. I couldn't reproduce it on my other systems, even
though the code technically applies to any system.
The breakage was: the metrics resulted in a difference of about 0.4
pixels being used for the descender with that particular font, resulting
in weird vertical alignment problems.
The offset needs to be computed against the ceil of the cell height,
which removes the fractional offset.
refs: https://github.com/wez/wezterm/issues/661
refs: https://github.com/wez/wezterm/issues/582
Replaces the last usage of ttf-parser with calling into freetype.
This removes a source of inconsistency, as ttf-parser doesn't support
all of the things that freetype does.
Notably, this prevents a weird error from blowing up codepoint coverage
calculations on a system where I have helvetica.bdf in my font dir for
long-forgotten reasons.
```
WEZTERM_LOG=wezterm_font=trace,info wezterm
```
will list fonts found in font_dirs and the builtin fonts.
It can't show all fonts found via the system locator, because
that only has an interface for finding fonts by matching name,
not listing all of them.
With this configuration:
```lua
local wezterm = require 'wezterm'
return {
font_dirs = {"/Users/wez/Downloads/Inconsolata"},
font = wezterm.font("Inconsolata"),
font_locator = "ConfigDirsOnly"
}
```
wezterm is now able to see the 74 variations that are available
in the single inconsolata ttf.
Running `WEZTERM_LOG=wezterm_font=trace wezterm` will log the
variations.
refs: https://github.com/wez/wezterm/issues/655
The repro scenario for this case was:
* open GNU nano
* hit enter twice
* type hello
* move the text cursor to the top line
* double click on hello
* hit enter
Prior to this commit, the selection would remain on the now-blank line
that previously held `hello`.
refs: #644
This has been a commonly requested feature in the past week,
and it's a reasonable one. The mux server inherited the
close-when-done behavior from when it used to be an alternate
front-end in the same executable as the gui, but it doesn't
need to be that way any more.
We also need to accomodate that case in the client: if the
newly attached domain doesn't result in any panes being imported,
we need to spawn a new command there in order to keep the client
alive. The pre-existing check for whether the mux was empty had
false positives because the local mux may still reference the
pane from the connection UI, which would finish closing out shortly
after we had decided not to spawn anything, and then the client
would close.
refs: https://github.com/wez/wezterm/issues/631
refs: https://github.com/wez/wezterm/issues/507
On macos, once all panes were closed, the GUI would request that the app
stop, but it wouldn't actually exit until a UI event occurred.
This was mostly noticeable when running debug builds from another
terminal.
Calling NSApp::abortModal is sufficient to knock us out of that state.
When line_height is specified, rather than applying the offset
to just the top of the cell, apply it in equal parts to the top
and the bottom so that the cell is vertically centered.
closes: https://github.com/wez/wezterm/issues/582
One of the default key assignments was registered as `SUPER+SHIFT+{`
which worked on macOS, but on Linux, would never match because the
keypress over there was (correctly) reporting as `SUPER+{`.
I originally thought that the user reported issue was a linux
normalization problem, but in looking deeper, the issue is really
that macos is doing something funky!
On macos we collect the interpreted key event as a string, and also
the interpretation of that event without any modifiers applied.
For letters this means that eg: `ALT-l` reports as `¬` for the
processed string and `l` for the unmodified string. That's good!
However, for punctuation we get a backwards result: SUPER+SHIFT+[
produces `[` for the processed text and `{` for the unmodified
text!
This commit tries to detect this, using a heuristic that is
potentially bad on non-US layouts: if both the processed and
unmodified strings are punctuation then we bias to the unmodified
version.
With that change, that key press is correctly reported as `SUPER+{`,
and we can fix the key assignment registration to reflect that.
I quickly checked the behavior of pressing that same physical key
combination with a DEU layout active, and it appears that the unmodified
stuff is also flipped there; we get a lower-case version of something
that I think should be uppercase. This commit doesn't change that
behavior:
```
key_event KeyEvent { key: Char('ü'), modifiers: NONE,
raw_key: Some(Char('Ü')),
raw_modifiers: SHIFT | SUPER,
raw_code: Some(33),
repeat_count: 1, key_is_down: true }
```
refs: https://github.com/wez/wezterm/issues/601
