This implementation doesn't include a timeout, but should be
recoverable via a SoftReset.
There's no query response either: I think I'm missing DECRQM
entirely at the moment.
refs: https://github.com/wez/wezterm/issues/882
4e99edf6f5 split the color into
thin/fat components, but overlooked copying the optional fat
part of the color.
That in turn broke sequences like:
* Set background color
* Erase to end of line
This commit teaches the sgr attribute cloning function to look
at the optional fat component.
refs: #962
Add the third device attributes (DA3) query+reply,
eliminating "unknown/unspecified CSI" error. Like
XTerm, simply reply with zeroes as opposed to site
codes or unique IDs.
https://vt100.net/docs/vt510-rm/DA3.html
* [terminfo] add smxx/rmxx, purge blink
Testing with WezTerm nightly indicates no blink support
available through the xterm \E[5m, and I didn't see any
support in the code -- purge it. smxx and rmxx, meanwhile,
have been added to indicate support for struck text.
* restore blink
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
The common palette indices are in the main cell attributes.
Using true color will allocate fat storage.
This allows reducing the Cell size from 32 -> 24 across the
implementation of storing 10 bpc color (it peaked at 40 in
the last couple of commits).
This adjusts the cursor position after emitting a sixel.
@dankamongmen: I don't have much of a sixel test suite to speak
of (cat snake.six :-p); I'd appreciate it if you could run
notcurses against this and confirm that it is doing something
sane!
At the very least, we shouldn't be warning about the unhandled
mode any more!
refs: https://github.com/wez/wezterm/issues/863
refs: https://github.com/dankamongmen/notcurses/issues/1743
Rust hasn't stabilized fallible allocation, so when we are presented
with an implausibly large sixel, Rust terminates the program; it's not
even a panick that we could potentially catch -> direct to termination.
This commit introduces an arbitrary constraint so that we can
avoid unconditionally terminating for this bad input case.
Thanks to @klamonte for sharing this test case!
A relatively recent commit made it possible for the cell storage
to be smaller than the viewport width.
Avoid panicking when erasing beyond the end of the cell storage.
We can simply NOP as that cell is already implictly erased.
closes: #847
ProbeHints would unconditionally load the terminfo based on $TERM
whever it was created, even if the caller had a pre-supplied
terminfo buffer.
Defer loading that until the caps instance is created.
refs: #817
There were two bugs here:
* \u8D (the utf8 encoded representation of 0x8d, aka: RI) was not
recognized as a C1 code and was instead passed through as printable
text.
* The \u8D is a zero-width sequence which means that a subsequent
set_cell call on the new empty-by-default line wouldn't allocate
any cells in the line array, and the assigment to the line would
panic.
This commit avoids the panic for the second case, and then fixes up
the vtparser to correctly recognize the sequence as a C1 control.
refs: https://github.com/wez/wezterm/issues/768
I noticed edenscm log -p (using streampager) cannot render 256 colors
if TERM is not "*-256color", despite forcing enabling true colors in
streampager (https://github.com/markbt/streampager/pull/28).
I tracked it down here. The problem is that we ask terminfo for colors
it does not claim to support. Fix it by using fallback CSI rendering
for colors exceeding the terminfo max color.
Using a boxed slice means that we hold exactly the memory required
for the file data, rather than the next-power-of-two, which can
be wasteful when a large number of images are being sent to
the terminal.
This is a API breaking change for termwiz, so bump its version.
refs: #534
```
echo -e "\033]777;notify;This is the notification title;This is the notification text\a"
```
Now pops up a notification in a similar manner to OSC 9, except
that this form allows setting both the title and the body separately.
refs: https://github.com/wez/wezterm/issues/489
I started this a while ago; it's pretty time consuming to produce
accessible and usable documentation for this sort of stuff, so
this isn't yet complete, but in the interest of avoiding additional
bit-rot, let's get this up.
refs: https://github.com/wez/wezterm/issues/257
It's been replaced with an opaque termwiz error type instead.
This is a bit of a more conservative approach than that in (refs: #407)
and has less of an impact on the surrounding code, which appeals to
me from a maintenance perspective.
refs: #406
refs: #407
You can install this into your $TERMINFO directory (default is
`$HOME/.terminfo`) by running:
`tic -x wezterm.terminfo`
from this data directory.
Once installed, you can set `TERM=wezterm`.
refs: https://github.com/wez/wezterm/issues/415
This allows us to support the kitty style underline sequence,
or the : separated form of the true color escape sequences.
refs: https://github.com/wez/wezterm/issues/415
These aren't currently rendered, but the parser and model now support
recognizing expanded underline sequences:
```
CSI 24 m -> No underline
CSI 4 m -> Single underline
CSI 21 m -> Double underline
CSI 60 m -> Curly underline
CSI 61 m -> Dotted underline
CSI 62 m -> Dashed underline
CSI 58 ; 2 ; R ; G ; B m -> set underline color to specified true color RGB
CSI 58 ; 5 ; I m -> set underline color to palette index I (0-255)
CSI 59 -> restore underline color to default
```
The Curly, Dotted and Dashed CSI codes are a wezterm assignment in the
SGR space. This is by no means official; I just picked some numbers
that were not used based on the xterm ctrl sequences.
The color assignment codes 58 and 59 are prior art from Kitty.
refs: https://github.com/wez/wezterm/issues/415
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
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.
@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
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
Moved the image and hyperlink portion of CellAttributes out
to a separate heap structure, saving 8 bytes per Cell
for the common case of no hyperlink and no image.
Replaces SmallVec with an internal TeenyString that only
occupies a single machine word and avoids heap allocation
in the common case on most architectures. This takes the
textual portion of Cell from 32 bytes to 8 bytes.
This commit introduces a new `leader` configuration setting
that acts as a modal modifier key.
If leader is specified then pressing that key combination
will enable a virtual LEADER modifier.
While LEADER is active, only defined key assignments that include
LEADER in the `mods` mask will be recognized. Other keypresses
will be swallowed and NOT passed through to the terminal.
LEADER stays active until a keypress is registered (whether it
matches a key binding or not), or until it has been active for
the duration specified by `timeout_milliseconds`, at which point
it will automatically cancel itself.
Here's an example configuration using LEADER:
```lua
local wezterm = require 'wezterm';
return {
-- timeout_milliseconds defaults to 1000 and can be omitted
leader = { key="a", mods="CTRL", timeout_milliseconds=1000 },
keys = {
{key="|", mods="LEADER|SHIFT", action=wezterm.action{SplitHorizontal={domain="CurrentPaneDomain"}}},
-- Send "CTRL-A" to the terminal when pressing CTRL-A, CTRL-A
{key="a", mods="LEADER|CTRL", action=wezterm.action{SendString="\x01"}},
}
}
```
refs: https://github.com/wez/wezterm/issues/274
The code assumed that OSC parameters were always numeric, but that isn't
the case.
In order to allow adding non-numeric OSC code we need to adjust and
allow for the codes to be any string value, and that's what this
commit does.
It shouldn't change any other behavior.
This commit teaches the terminal model about the overline attribute
and the SGR codes to enable/disable overline.
The render layer in the GUI doesn't yet understand this attribute.
Now that we're reporting a higher level from DA1, apps are asking
more exotic codes. eg: vttest now asks about the conformance level,
but doesn't have a timeout on that request and hangs if we don't
respond.
This commit adds a bit of plumbing to make it easier to consume
and parse DCS sequences that are known to be short/short-lived,
and teaches the term layer to respond to a couple of possible
DECRQSS queries.
This is an xterm sequence that adjusts how the terminal
encodes keyboard output.
This commit teaches termwiz to parse and encode the sequence,
but doesn't teach the terminal emulator to do anything with it
at this time.
I'm adding this because vim sends these sequences and I wanted
to understand what they were for.
This commit adds support for left/right margins and has been
tested against esctest, with a final status of:
```
309 tests passed, 239 known bugs
```
"known bugs" also includes unimplemented features; we have a
similar degree as iTerm2.
As of this commit, we now report as a vt520ish machine to DA1.
I confess to not having read enough of the relevant docs
to know whether this is totally righteous.
We weren't parsing `CSI 2H`; we'd decide that because it needed two
parameters it was an error instead of defaulting the omitted second
parameter to 1.
