1
1
mirror of https://github.com/wez/wezterm.git synced 2024-12-19 11:21:39 +03:00
Commit Graph

2937 Commits

Author SHA1 Message Date
Wez Furlong
7aa65fef80 docs: update pages workflow 2020-12-09 14:11:42 -08:00
Wez Furlong
526df72544 textwrap -> 0.13 2020-12-09 14:07:35 -08:00
Wez Furlong
8eb0dac92c Update lru -> 0.6 2020-12-09 14:04:56 -08:00
Wez Furlong
6db583388f cargo update
(this will probably annoy dependabot)
2020-12-09 13:58:44 -08:00
Wez Furlong
22b4e99c82 tidy up default_dpi vs DEFAULT_DPI
This commit breaks the dependency from config -> window,
which in turn breaks the dependency from mux-server -> x11 libs
on linux.
2020-12-09 13:48:23 -08:00
Wez Furlong
c6334a45dd extract window::input to wezterm-input-types 2020-12-09 13:48:23 -08:00
Wez Furlong
eec27d81e3
Create dependabot.yml 2020-12-09 13:48:13 -08:00
Wez Furlong
dfde0c8809 term: revise color cube in the default palette
This commit adjusts the default color palette to use the same color
cube calculation as xterm; it isn't the ideal color cube calculation
and results in slightly brighter colors.

This commit also memoizes the default palette calculation so that
it isn't recomputed each time a palette is created.

refs: https://github.com/wez/wezterm/issues/348
2020-12-09 00:52:24 -08:00
Wez Furlong
d99b025e24 docs: link to new GitHub Discussions thingy 2020-12-08 20:32:46 -08:00
Wez Furlong
dd11fc606a ci: maybe fix centos 8
The internet suggests that the name should be lowercase.
Why this suddenly broke is beyond me.
2020-12-07 21:34:30 -08:00
Wez Furlong
2888428dda wezterm-font: add system font fallback on macOS
Teach the core text locator how to obtain the system fallback list
and add that to the fallback.

Fixup handling of ttc files on macOS; we'd always assume index 0
when extracting font info from the font descriptor.  We now make
the effort to enumerate the contents of the TTC and find a match.
2020-12-06 22:23:39 -08:00
Wez Furlong
92827a1bea wezterm: default dpi on macOS is now 72
https://wiki.lazarus.freepascal.org/Cocoa_DPI states that the dpi
on macOS is 72.  That matches up to the experimental results reported
in #332 (in which 74.0 appears about the right size).

This commit introduces a `DEFAULT_DPI` constant that is set to 72 on
macOS and 96 on other operating systems.

The result of this is that a 10 point Menlo font now appears to be
the same size in Terminal.app and WezTerm.app.

refs: https://github.com/wez/wezterm/issues/332
2020-12-06 18:34:06 -08:00
Wez Furlong
b2be2963a1 wezterm: fixup input processing for Option/dead keys
This commit improves input processing on macOS; passing the keyUp
events to the input context is required for dead keys to correct
process their state transitions.

In addition, we weren't passing key events through if any modifiers
were down; for dead keys we need to allow Option through.

This commit rigs up a little bit of extra state to avoid double-emitting
key outputs from the input context.

Lastly, the virtual key code is passed through to the KeyEvent to
enable binding to raw keys per 61c52af491

refs: #357
2020-12-06 17:49:26 -08:00
Wez Furlong
19843ba8f3 wezterm-gui: fixup compilation 2020-12-06 14:30:45 -08:00
Wez Furlong
61c52af491 wezterm: add raw_code concept to input layer
This commit is a bit noisy because it also meant flipping the key map
code from using the termwiz input types to the window input types, which
I thought I'd done some time ago, but clearly didn't.

This commit allows defining key assignments in terms of the underlying
operating system raw codes, if provided by the relevant layer in the
window crate (currently, only X11/Wayland).

The raw codes are inherently OS/Machine/Hardware dependent; they are the
rawest value that we have available and there is no meaningful
understanding that we can perform in code to understand what that key
is.

One useful property of the raw code is that, because it hasn't gone
through any OS level keymapping processing, its value reflects its
physical position on the keyboard, allowing you to map keys by position
rather than by value.  That's useful if you use software to implement
eg: DVORAK or COLEMAK but want your muscle memory to kick in for some of
your key bindings.

New config option:

`debug_key_events = true` will cause wezterm to log an "error" to stderr
each time you press a key and show the details in the key event:

```
2020-12-06T21:23:10.313Z ERROR wezterm_gui::gui::termwindow > key_event KeyEvent { key: Char('@'), modifiers: SHIFT | CTRL, raw_key: None, raw_modifiers: SHIFT | CTRL, raw_code: Some(11), repeat_count: 1, key_is_down: true }
```

This is useful if you want to figure out the `raw_code` for a key in your
setup.

In your config, you can use this information to setup new key bindings.
The motivating example for me is that because `raw_key` (the unmodified
equivalent of `key`) is `None`, the built-in `CTRL-SHIFT-1` key
assignment doesn't function for me on Linux, but I can now "fix" this in
my local configuration, taking care to make it linux specific:

```lua
local wezterm = require 'wezterm';
local keys = {}

if wezterm.target_triple == "x86_64-unknown-linux-gnu" then
  local tab_no = 0
  -- raw codes 10 through 19 correspond to the number key 1-9 positions
  -- on my keyboard on my linux system.  They may be different on
  -- your system!
  for i = 10, 20 do
    table.insert(keys, {
      key="raw:"..tostring(i),
      mods="CTRL|SHIFT",
      action=wezterm.action{ActivateTab=tab_no},
    })
    tab_no = tab_no + 1
  end
end

return {
  keys = keys,
}
```

Notice that the key assignment accepts encoding a raw key code using
a value like `key="raw:11"` to indicate that you want a `raw_code` of
`11` to match your key assignment.  The `raw_modifiers` portion of
the `KeyEvent` is used together with the `raw_code` when deciding
the key assignment.

cc: @bew
2020-12-06 13:41:29 -08:00
Wez Furlong
4e7f3cc75a window: add optional KeyCode::raw_code field
This allows stashing the raw key identifier from the keyboard layer.
Interpreting this value is hardware and OS dependent.

At this time, only X11/Wayland implementations populate this value,
and there is no way to do key assignment based upon it.
2020-12-06 13:41:29 -08:00
Wez Furlong
d6a9ed5ae7 window: x11: remove a little redundant code from key processing 2020-12-06 13:41:29 -08:00
Wez Furlong
ba9bc30b79 harfbuzz: skip some unused bits
don't bother building the coretext or uniscribe bits of harfbuzz
2020-12-05 14:19:47 -08:00
Wez Furlong
0fa2edb1f4 wezterm: fix panic in early startup
164adb78e3 added blowing some
opengl related state during resize, however, on some systems
(BigSur with M1 silicon, perhaps also Intel?) and Windows 10
can generate a resize event before we've spun up opengl, so
we need to make this conditional.

refs: #359
closes: #358
2020-12-05 10:43:20 -08:00
Wez Furlong
e86d949dae cargo update
We need a newer version of ring in order to compile on M1

refs: #343
2020-12-05 10:35:00 -08:00
Wez Furlong
bbb953610d wezterm: fix x-scale calculation
Need to account for the number of cells occupied by the glyph,
otherwise we'll always scale to a single cell for double width
glyphs.

refs: #342
2020-12-04 22:36:20 -08:00
Wez Furlong
215a3bb297 docs: link to fedora 33 nightly builds 2020-12-04 22:09:48 -08:00
Wez Furlong
ab54d1f897 Updates for building on Fedora 33 2020-11-29 10:26:11 -08:00
evs-ch
1a42b17727
Fixes building on aarch64 (#356)
827d94a seems to have broken building on aarch64. The fix is pretty
much adapted from bf962c8.
I know little about rust, so I might've missed some obvious issues with
this PR - it seems to work so far, though.
2020-11-26 20:41:04 -08:00
Wez Furlong
214390ba5a wezterm-font: remove some dead code 2020-11-25 22:12:40 -08:00
Wez Furlong
6ccef46989 wezterm-font: compute codepoint coverage for font-dirs
This commit adds support for computing the codepoint coverage for fonts
loaded from font-dirs and the built-in, in-memory fonts.

What this means is that if you have eg: a font with chinese glyphs in
your font-dirs but not explicitly listed in your wezterm config, if
chinese text is rendered and no match from your config is found, wezterm
will be able to find the font from your font-dirs and use that
implicitly.

Computing the codepoint coverage is relatively expensive so we defer it
until we need to perform it, and cache it.
2020-11-25 20:41:09 -08:00
Wez Furlong
d934a0ae88 wezterm-font: move FontDatabase into FontConfiguration
Previously, we'd enumerate the font dirs on every font resolve for
every bit of styled text.

This moves the new FontDatabase instances to be single instanced
in the FontConfiguration.  The font-dirs will be scanned once
on a config reload, but the built-in in-memory fonts will only
every be enumerated once per FontConfiguration instance.
2020-11-25 19:21:51 -08:00
Wez Furlong
b0bee3b036 wezterm-font: introduce FontDatabase
This tidies up the font-dir and built-in font management a little
bit and paves the way for codepoint -> font resolution for fonts
discovered in font-dirs.
2020-11-25 19:15:08 -08:00
Wez Furlong
164adb78e3 wezterm: blow more caches when scaling changes
The recent addition of dynamic fallback resolution highlighted this
issue.

The test scenario is:

1. Output some glyphs that need dynamic fallback
2. ctrl-+ to change the font scaling
3. rasterization fails because of some bad cached state; the font_idx's
   were invalidated by the scale change which reset the dynamically
   discovered fallback fonts.

The resolution is to blow the glyph and shape caches when scaling
is changed.
2020-11-25 16:19:56 -08:00
Wez Furlong
80488ea14d improve freetype error context
Tag some font related errors with more context.
This makes it a bit easier to understand where a problem
is coming from.
2020-11-25 16:19:56 -08:00
Wez Furlong
4fd574cc7f freetype: enable FT_Error_String
By default, freetype doesn't include error strings and FT_Error_String
will always return NULL.  Turn on the compile time option that makes
this function useful!
2020-11-25 16:19:56 -08:00
Wez Furlong
ba44548d46 wezterm-font: teach gdi locator how to search for fallback fonts
This commit uses a bit of DirectWrite to discover which font(s)
can be used to render a set of codepoints.

While hooking this up, I found that the method we were using
to extract the font data didn't handle TTC data so this commit
improves some parser diagnostics and handling for that.

refs: https://github.com/wez/wezterm/issues/299
2020-11-25 16:19:56 -08:00
Wez Furlong
58eb8e3614 wezterm-font: move caching of freetype font size into Face
Profiling showed that set_font_size was a hotspot.  While there was
caching of the size info at the shaper layer, it was also needed in
the raster layer, so move it into the raster layer from the shaper
layer.

refs: #353
2020-11-25 09:20:14 -08:00
Benoit de Chezelles
c7dc44a538 Update fonts.markdown 2020-11-24 18:26:27 -08:00
Wez Furlong
5fbb6a4400 wezterm-font: cache metrics lookup in harfbuzz shaper
98f289f511 causes more metrics retrieval
than in earlier versions; each unchached glyph render would trigger
a metrics recompute for the relevant font.

Add a simple cache for this.

refs: #353
2020-11-24 18:19:49 -08:00
Wez Furlong
827d94a9a8 wezterm-font: add find-fall-back-for-codepoints concept
This commit makes some adjustments to FontConfiguration and LoadedFont
such that it the shaper is unable to resolve a (non-last-resort) font
for a set of codepoints, the locator can be used to try to find a
font that has coverage for those codepoints.

At the moment this is a bit limited:

* Only the font-config locator implements this function
* The directory based locator isn't actually an implementor of the
  locator trait and doesn't have a way to be invoked for this.
2020-11-24 18:03:32 -08:00
Wez Furlong
3652a8360f wezterm-font: fix typo in error message 2020-11-24 12:37:11 -08:00
Simon Legner
93ef3a7572 docs: fix capitalization of PageUp/PageDown 2020-11-24 10:45:42 -08:00
Wez Furlong
3b69586416 wezterm: add allow_square_glyphs_to_overflow_width = "WhenFollowedBySpace"
Adds an option to control how wide glyphs (more specifically: square
aspect glyphs) are scaled to conform to their specified width.

The three options are `Never`, `Always`, and `WhenFollowedBySpace`.

When a glyph is loaded, if it is approximately square, this option is
consulted.  If overflow is permitted then the glyph will be scaled
to fit only the height of the cell, rather than ensuring that it fits
in both the height and width of the cell.

refs: #342
2020-11-24 10:38:20 -08:00
Wez Furlong
d97e4e44a9 use double wide glyphs for square emoji 2020-11-24 10:17:44 -08:00
Wez Furlong
6e8f8298af wezterm: explain where the font came from in fallback errors
Make an effort to explain what failed to load and where it came from,
and funnel users to the documentation on font configuration.

The message presented is slightly different depending on whether
we think that the font was their primary font, an explicitly
specified font_rule or an implicitly synthesized font_rule.

refs: #340
2020-11-24 08:49:26 -08:00
Benoit de Chezelles
eee40f7d17 Update permute_any_mods.md 2020-11-23 17:22:21 -08:00
Benoit de Chezelles
2963520a1e Update permute_any_or_no_mods.md 2020-11-23 17:22:21 -08:00
Wez Furlong
98f289f511 wezterm-font: improve fallback font scaling
Use the scaling factor between the font metrics for the base font
and those of the fallback font selected for a given glyph.

The scenario is this: the base font is typically the first one selected
from the font configuration.  There may be multiple fallback fonts that
are different sizes; for instance, the Font Awesome font has glyphs that
are square in aspect and are thus about twice the width of a typical
textual monospace font.  Similarly, Noto Color Emoji is another square
font but that has a single set of bitmap strikes at a fixed 128 px
square.

The shaper returns advance metrics in the scale of the containing font,
and the rasterizer will target the supplied size and dpi.

We need to scale these to match the base metrics.

Previously we used a crude heuristic to decide whether to scale,
and that happened to work for Noto Color Emoji but not for Font Awesome,
whose metrics were just inside the bounds of the heuristic.

This commit allows retrieving the metrics for a given font_idx so
that we can compute the correct scale factor without any heuristics,
and applies that to the rasterized glyph.

refs: https://github.com/wez/wezterm/issues/342
2020-11-23 16:59:30 -08:00
Wez Furlong
65ac2269dd wezterm-font: fix exact match of full font name
Don't short circuit on just the family portion of the name;
if the criteria don't match there, we should fall back to
test against the full font name.

closes: https://github.com/wez/wezterm/issues/341
2020-11-23 15:01:19 -08:00
Benoit de Chezelles
d4d3e70a9b Update permute_any_or_no_mods.md 2020-11-23 14:52:45 -08:00
Wez Furlong
3309803925 ci: speculative fix for C++11 build break in harfbuzz
Weird that this was set to not enable C++, but I suspect it is the
reason why the C++11 compiler flag isn't being added to resolve this:

```
warning: harfbuzz/src/hb-meta.hh:41:18: warning: variadic templates are a C++11 extension [-Wc++11-extensions]
warning: template<typename... Ts> struct _hb_void_t { typedef void type; };
```
2020-11-23 14:33:47 -08:00
Wez Furlong
eabfa3c0f8 term: fix ALT-Escape
This appears to have been accidentally broken as part of the churn
around building out CSI-u key encoding in
6289c08a4e

closes: https://github.com/wez/wezterm/issues/338
2020-11-23 14:20:43 -08:00
Wez Furlong
a063d20cf0 wezterm: improve shaping of emoji
This is one of those massive time sinks that I almost regret...
As part of recent changes to dust-off the allsorts shaper, I noticed
that the harfbuzz shaper wasn't shaping as well as the allsorts one.

This commit:

* Adds emoji-test.txt, a text file you can `cat` to see how well
  the emoji are shaped and rendered.

* Fixes (or at least, improves) the column width calculation for
  combining sequences such as "deaf man" which was previously calculated
  at 3 cells in width when it should have just been 2 cells wide, which
  resulted in a weird "prismatic" effect during rendering where the
  glyph would be rendered with an extra RHS portion of the glyph across
  3 cells.

* Improved/simplified the clustering logic used to compute fallbacks.
  Previously we could end up with some wonky/disjoint sequence of
  undefined glyphs which wouldn't be successfully resolved from a
  fallback font.  We now make a better effort to consolidate runs of
  undefined glyphs for fallback.

* For sequences such as "woman with veil: dark skin tone" that occupy a
  single cell, the shaper may return 3 clusters with 3 glyphs in the
  case that the font doesn't fully support this grapheme.  At render
  time we'd just take the last glyph from that sequence and render it,
  resulting in eg: a female symbol in this particular case.  It is
  generally a bit more useful to show the first glyph in the sequence
  (eg: person with veil) rather than the gender or skin tone, so the
  renderer now checks for this kind of overlapping sequence and renders
  only the first glyph from the sequence.
2020-11-23 13:45:38 -08:00
Wez Furlong
dc453f2eed deps: update bundled harfbuzz to 2.7.2 2020-11-23 08:43:53 -08:00