The current master of allsorts supports color fonts in both bitmap and
svg varieties. I'm interested to see if I can teach wezterm to render
the svg based variety in a subsequent diff.
First though, it's times to dust off our allsorts shaper logic.
This commit updates to point to the current master of allsorts at the
time of writing; there's a little bit of API fanout that makes it a bit
easier to manage font fallback.
The fallback logic has been improved so that we can now successfully
fall back to the emoji font.
The shaping logic has been improved so that we turn on the options that
enable ZWJ for combining sequences of emoji, such as "man health
worker".
Running with the allsorts shaper enabled produces generally superior
emoji/ligature substitution results compared to harfbuzz with Noto Color
Emoji; the "man health worker" and the flags (eg: `flag: England`) from
the subdivsion-flag section don't get substituted at all with harfbuzz,
but do produce appropriate glyphs with allsorts.
refs: https://github.com/wez/wezterm/issues/66
This causes `tmux -CC attach` to enter control mode and patch
into the terminal, printing out parsed event messages.
refs: https://github.com/wez/wezterm/issues/336
When subpixel or greyscale AA are in use, the glyph data includes
some lighter and darker shaded pixels. That's their purpose,
but if the fg and bg color are the same, the expectation is that
the glyph is invisible and we don't want "phantom" pixels around
the character.
This commit adjusts the shader to set the color to transparent
when the fg and bg are the same, and we are not rendering a color
emoji.
refs: #331
This makes it possible to configure wezterm to eg: triple click
on command input (or output) to select the entire input or output
without messing around trying to find the bounds.
The docs have an example of how to configure this; it requires
setting up shell integration to define the appropriate semantic
zones.
9892b16d40 adjusted how the text
colors are produced; it resulted in some ugly dark edges, especially
on lighter backgrounds.
This commit routes that tint via an alpha compositing helper which
produces smoother edges.
refs: #320
This commit more cleanly separates the load from the render flags,
and fixes up the render call; at some point this got messed up such
that we'd never end up with freetype returning subpixel format data
(LCD) and instead we'd only ever get grayscale data.
With that fixed, it's apparent that the colorization of the glyph
data was wonky in the shader so this commit also cleans this up.
refs: #320
refs: #121
If you have a primary font whose height is a bit more than double the
width then a double-wide emoji would be scaled to a bit more than two
cells in width.
This commit adjust the glyph scaling to check both the x and y scaling
to ensure that they glyph fits within the appropriate number of cells.
This has the consequence of rendering eg: the heart emoji smaller than
in previous versions; the heart glyph is typically square but the
broadly used concept of width for the heart unicode character is a
single cell. Previously we'd incorrectly render this double wide.
I'm not sure of a way to do better than we are right now because
freetype doesn't provide much help for scaling this kind of bitmap
font AFAICS.
refs: #320
This commit provides a shell script that hooks into bash and zsh
to enable OSC 7 and semantic zones.
The packaging for Fedora and Debian deploys that script to
/etc/profile.d.
This command formats an OSC 7 escape sequence to inform the terminal
of the working directory.
It has two optional arguments:
* The hostname - if unspecified the hostname of the system will be used
* The working directory - if unspecified the working directory of the
process will be used
This command formats the hostname and working directory into a `file://`
URL and emits an OSC 7 escape sequence.
The intent of this is to make it a bit easier to produce shell
integration scripts for various shell environments without trying
to implement URL encoding in eg: bash.
@yoichi reports that:
```bash
printf "\x1bPqh"
```
would panic wezterm; the issue was that the maximum x value was
only being updated for newlines and that sequence didn't include it.
refs: #217
There were two problems:
* It was using an old code path that didn't even try to resolve the cwd
* The NewWindow code path would "forget" the originating window and then
fail to resolve the current pane + path from the new, empty window
that it is building.
closes: https://github.com/wez/wezterm/issues/322
Adds some supporting methods for computing the `SemanticZone`s
in the display and a key assignment that allows scrolling the
viewport to jump to the next/prev Prompt zone.
This commit allows the terminal to tag cells with their semantic
type, as defined by OSC 133 escape sequences.
The gist of it is that each cell is now semantically one of:
* Output (eg: from the activity performed by the user. This is the
default)
* Input (eg: something that the user typed as input)
* Prompt (eg: "uninteresting" chrome/UI from the shell)
The semantic type is applied almost exactly like an SGR attribute,
except that resetting SGR doesn't clear the semantic type.
Tagging the cells in this way allows for smarter UX in the future;
for example, selecting the entire input or output from the last
command without fiddling around to avoid the prompt line(s),
or "paging up" to a prior prompt rather than page.
This doc covers those escapes as used in domterm, iterm2 and other
terminals:
https://gitlab.freedesktop.org/Per_Bothner/specifications/blob/master/proposals/semantic-prompts.md
This is an example of how to configure the shell to emit these
sequences; I'll add a proper little blob of shell specifically
for wezterm in a later commit:
https://github.com/PerBothner/DomTerm/blob/master/tools/shell-integration.zsh
Full error
```
error[E0277]: can't compare `&[u8]` with `std::vec::Vec<u8>`
--> wezterm-gui/src/gui/termwindow.rs:817:40
|
817 | if existing.data() == data {
| ^^ no implementation for `&[u8] == std::vec::Vec<u8>`
|
= help: the trait `std::cmp::PartialEq<std::vec::Vec<u8>>` is not implemented for `&[u8]`
error: aborting due to previous error
```
I've had a FIXME in here for a while to check the positioning,
but never got around to it.
The onefetch folks have an app that does care about this,
so it's time to resolve it!
This commit adjusts the cursor position for the iterm case
(not the sixel case), and results in both:
running in xterm:
```
onefetch --image ~/Downloads/squirrel.png
```
running in wezterm:
```
TERM_PROGRAM=iTerm.app onefetch --image ~/Downloads/squirrel.png --image-backend=iterm
```
```
onefetch --image ~/Downloads/squirrel.png --image-backend=sixel
```
showing consistent positioning.
refs: https://github.com/wez/wezterm/issues/317
refs: https://github.com/o2sh/onefetch/pull/305
This is basically the same issue as
70fc76a040 but on macOS. Now that we're
using EGL in more places, the same sort of check needs to used in more
places!
Will need to do the same on Windows in a follow-up commit.
refs: #316
