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
This reverts to the original resize behavior of padding out
the display when resizing taller, but only for Windows systems.
More explanation in the comments in the code.
refs: #138
Needed to re-order a couple of things to match recent changes.
Also: don't hard fail if the ssh server rejects a setenv request,
just log the error instead.
This seems to make our resize behavior a bit nicer and more
consistent with eg: xterm.
Previously we'd consider the previously existing scrollback
as immutable and prefer to add excess blank lines of padding
when making the window taller.
In practice that meant that content would scroll back when
making the window taller, which is annoying.
This commit removes that constraint and instead will prefer
to maintain the cursor position relative to the top of the
viewport when the size changes.
refs: #138
Not 100% sure that this is it, but it seems much less likely that
artifacts will appear in conjunction with transparency when the window
shadow effect is disabled; I didn't see the ghosting with this disabled,
but I sometimes dididn't see it with it enabled, so I'm not sure that we
have a 100% reliable reproduction, and thus am not sure that this is a
fix.
I found mention of disabling the shadow in some example code on
stackoverflow when I was first researching this, but it wasn't supplied
with an explanation. Perhaps this is why?
Longer term we might want to be smarter about turning off the shadow
only when the opacity is != 1.0, but at the moment the window layer
can't see the config, so let's just default it off for the moment
until we see if it does the trick.
refs: #310
This avoids having a green (by default) border around the cursor.
The dynamic color escape sequences have been updated to also
change the border color when the cursor background color is changed.
A consequence of reducing the initial texture size is that for
larger starting font sizes it isn't big enough. We need to make
a couple of passes to determine the required size, so that's
what this commit does.
refs: #307
This commit introduces a small, bounded, LRU cache for recently
decoded images.
This allows the same image ID to be used in the cache that the
same image bits are repeatedly sent to the terminal.
This is advantageous because it reduces the amount of texture
space required by the gui layer.
I changed this to `wezterm-gui` thinking it would be a hair more
efficient, but it makes it difficult to access the cli side of
things from the appimage.
This wasn't used by anything and the version was getting pretty stale.
Upgrading is awkward because newer versions pull in an incompatible
freetype library version.
Wheel events wouldn't get reported to eg: vim in wsl if the
window's X position was larger than the window width due to
mouse wheel messages being reported with screen coordinates
rather than client coordinates.
This commit addresses that.
This commit moves a bunch of stuff around such that `wezterm` is now a
lighter-weight executable that knows how to spawn the gui, talk to
the mux or emit some escape sequences for imgcat.
The gui portion has been moved into `wezterm-gui`, a separate executable
that doesn't know about the CLI or imgcat functionality.
Importantly, `wezterm.exe` is no longer a window subsystem executable
on windows, which makes interactions such as `wezterm -h` feel more
natural when spawned from `cmd`, and should allow
`type foo.png | wezterm imgcat` to work as expected.
That said, I've only tested this on linux so far, and there's a good
chance that something mac or windows specific is broken by this
change and will need fixing up.
refs: #301
When allocating space in the texture atlas, we typically use
a small padding to avoid accidentally interpolating textures
into glyphs.
When it comes to rendering images via iterm2 or sixel image
protocols, the image emitted by the user may not exactly fill
the cell dimensions, and due to the how the shader works to
apply those textures we could end up revealing nearby images
in the texture when displaying an unrelated image.
This commit adjusts the texture atlas allocation when making
space for image protocol textures; excess padding based on
an overestimate of the cell dimensions is added to the right
and bottom of the image, guaranteeing that that border will
be filled with transparent pixels.
This is a bit wasteful of texture space, but isn't egregiously
bad and is easy to reason about and makes things look less
janky.
refs: #292
There was an integer conversion happening when taking the
per-cell image texture coordinates and applying them to the
texture atlas image coordinates.
This commit replaces that math with floating point and corrects
the visual artifacts within squirrel.png.
refs: #292
