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
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.
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.
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
When returning the title string we prefer to return the OSC 1 Icon
title (which is interpreted as "tab title" by some emulators and
shell toolkits) on the basis that it will have been setup for
display in a more limited width than the overall window title
and will thus likely be a better choice to show to the user.
If OSC 1 hasn't been set then we'll fall back to the OSC 2 window
title as before.
refs: https://github.com/wez/wezterm/issues/247
OSC 1 is defined as setting the "Icon Title".
OSC 2 is defined as setting the "Window Title".
OSC 0 sets both of those.
Some terminal emulators will display the Icon title as the tab
title.
Wezterm doesn't make a distinction between any of those things; the
title is applied (during escape sequence parsing) to the terminal
instance in isolation from any other terminals; when the GUI layer
renders the titlebar it is composed from the title in the active tab.
refs: https://github.com/wez/wezterm/issues/247
I'm wondering if the non-deterministic portion of
refs: https://github.com/wez/wezterm/issues/241
might be due to splitting of data across multiple write calls.
This commit adopts the use of BufWriter around the writer so that
we can buffer up and explicitly flush the responses to the terminal.
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.
We were unconditionally adding the encoded form of the modifier
mask (eg: appending `;1~` to the sequence) and not all apps know
how to interpret that.
refs: https://github.com/wez/wezterm/issues/227
While testing this with esctest, it was apparent that xterm deviates
from the DEC docs by allowing a minimum region size smaller than 2,
so adjust our restriction accordingly.
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.
With this commit, we now survive a reinstall or upgrade of the nvidia
drivers on my Windows sytem without crashing.
This commit allows notifying the application of the context loss
so the application can either try to reinit opengl or open a new
window as a replacement and init opengl there.
I've not had success at reinitializing opengl after a driver upgrade;
it seems to be persistently stuck in a state where it fails to allocate
a vertex buffer.
SO, the state we have now is that we try to reinit opengl on a new
window, and if that fails, leave it set to the software renderer.
This isn't a perfect UX, but it is better than terminating!
refs: https://github.com/wez/wezterm/issues/156
This was originally intended to be swept in and dealt with as part of
adopting CSI-u (refs: https://github.com/wez/wezterm/issues/63) but the
default shift-space mapping is super irritating in vim (refs:
https://github.com/wez/wezterm/issues/126) so it got partially walked
back, but as a consequence we accidentally dropped the modifiers from
those keys (refs: https://github.com/wez/wezterm/issues/213 refs:
https://github.com/wez/wezterm/issues/214).
This commit restores the modifiers for that case.
In addition, since we now have a way to plumb configuration directly
into the term crate, this adds a config option to enable CSI-u for those
that want to use it.
If the image is smaller than the cell size we could end up
rounding that dimension to zero and ultimately not render
the texture to the cell.
This commit adjusts the math to round up, which yields
better results for the test in refs: https://github.com/wez/wezterm/issues/211
I noticed that we still weren't quite right.
I think the net change is really just that we must force
the use of the CSI representation when using CTRL/SHIFT
modifiers.
refs: https://github.com/wez/wezterm/issues/203
We were treating DECCKM as the sole thing to enable application
cursor reporting, but looking closely at the docs, that mode only
takes effect when both DECANM (Vt52 emulation mode) AND DECKPAM
(application keypad mode) are both active.
neovim enables DECCKM and DECKPAM but not DECANM.
refs: https://github.com/wez/wezterm/issues/203
