Add `VTParser::is_ground`, which is true if the VTParser is in the
"ground" state, i.e. it has no stored state that will affect the
interpretation of future input characters.
This is included only in the json output mode.
Note that this does not and cannot include positioning information known
only to the GUI, as there may not be a GUI. That means that window
position, tab bar and padding data are not known and not able to be
returned via this interface.
```
; wezterm cli list --format json
[
{
"window_id": 0,
"tab_id": 0,
"pane_id": 0,
"workspace": "default",
"size": {
"rows": 24,
"cols": 80,
"pixel_width": 1040,
"pixel_height": 672,
"dpi": 124
},
"title": "wezterm cli list --format json -- wez@foo:~",
"cwd": "file://foo/home/wez/",
"cursor_x": 0,
"cursor_y": 2,
"cursor_shape": "Default",
"cursor_visibility": "Visible",
"left_col": 0,
"top_row": 0
}
]
```
refs: #2319
This makes those fields usable in `wezterm cli list --format json`.
This doesn't change the ABI of the mux protocol, but prior to
this commit, those fields were always 0.
refs: #2319
They prevented using other types of mouse events!
We don't have a good way to specify that kind of alias, so for now,
take it out and replace the examples in the docs with the more verbose
equivalents.
refs: #2173
refs: #2296
Adjusts how mouse events are matched so that we can now indicate whether
mouse reporting and alt-screen should be considered as part of the event
trigger criteria.
refs: #2173
refs: #581
`4` is actually defined as CMYK according to ITU-T Rec. T.416:
> A parameter substring for values 38 or 48 may be divided by one or more separators (03/10) into parameter elements,
> denoted as Pe. The format of such a parameter sub-string is indicated as:
>
> Pe : P ...
>
> Each parameter element consists of zero, one or more bit combinations from 03/00 to 03/09, representing the digits
> 0 to 9. An empty parameter element represents a default value for this parameter element. Empty parameter elements at
> the end of the parameter substring need not be included.
>
> The first parameter element indicates a choice between:
>
> 0 implementation defined (only applicable for the character foreground colour)
> 1 transparent;
> 2 direct colour in RGB space;
> 3 direct colour in CMY space;
> 4 direct colour in CMYK space;
> 5 indexed colour.
refs: 6e9a22e199 (commitcomment-79669016)
This commit extends the sgr color parser to support a wezterm
extension that I just made up:
```
printf "\e[48:4:255:0:0:60mhello\e0m"
```
The `4` is wezterm specific and denotes 4 channel color, in this case
RGBA. red is 255, green is 0, blue is 0 and alpha is 60; the values are
interpreted as u8 values.
CSI 38 (fg), 48 (bg) and 58 (underline) support this.
refs: https://github.com/wez/wezterm/issues/2313
This doesn't really change any behavior, but adjusts the types
such that CSIs that set colors have the potential to track the
alpha channel and that can make it through to the GUI/render layer.
Just clamp it to the current physical, non-scrollback portion
of the screen.
This avoids a panic but doesn't address the screen size mismatch
in the associated issue.
refs: https://github.com/wez/wezterm/issues/2133
There was a race condition where we could leave the tab
active index pointing to the wrong pane.
That meant that the tab information computed by the gui
layer would see no panes marked as active, and thus would
end up with no active tab.
This commit fixes that by clamping the active index to
the number of panes.
refs: https://github.com/wez/wezterm/issues/2304
The recent work on the scrollback made it easier to constrain the
search region, so expose those parameters to the Pane::search
interface and to the mux protocol.
Use those new parameters to constrain quickselect search to
1000 rows above and below the current viewport by default, and
add a new parameter to QuickSelectArgs that allows overriding that
range.
A follow-up commit could make the search/copy overlay issue a series
of searches in chunks so that it avoids blocking the UI when
searching very large scrollback.
refs: https://github.com/wez/wezterm/pull/1317
In order to avoid searching for "c", "ca", "cat" when typing "cat",
this commit introduces a hard-coded 350ms debounce.
refs: https://github.com/wez/wezterm/issues/1569
If you typed "cat" in the search, the chances are that wezterm
would kick off a search for "c" before you finished typing,
then "ca" and then finally "cat".
There was a race:
clear by_line highlights,
queue search for "c"
clear by_line highlights,
queue search for "ca"
clear by_line highlights,
queue search for "cat"
accumulate highlights for "c" into by_line
accumulate highlights for "ca" into by_line
accumulate highlights for "cat" into by_line
so the final result was a superposition of all of those results,
which was weird!
The fix is simple: clear by_line when we get the results of
an async search.
When adding sparse ranges the cartesian product of range combinations
was explored to find intersections, which is pretty awful if there
are 1 million entries to be inserted.
This commit employs binary search to reduce the complexity, at
the expense of requiring that the internal range array is sorted.
