Allows the following assignment actions; I was just over-using z for
no real reason, I'm not suggesting that these are good assignments.
```
-- move the cursor backwards to the start of the current zone, or
-- to the prior zone if already at the start
{ key = 'z', mods = 'NONE', action = act.CopyMode 'MoveBackwardSemanticZone' },
-- move the cursor forwards to the start of the next zone
{ key = 'Z', mods = 'NONE', action = act.CopyMode 'MoveForwardSemanticZone' },
-- start selecting by zone: both the start point and the cursor
-- position will be expanded to the containing zone and the union
-- of those two will be used for the selection
{
key = 'z',
mods = 'CTRL',
action = act.CopyMode { SetSelectionMode = 'SemanticZone' },
},
-- like MoveBackwardSemanticZone by only considers zones of the
-- specified type
{ key = 'z', mods = 'ALT', action = act.CopyMode { MoveBackwardZoneOfType ='Output' }},
-- like MoveForwardSemanticZone by only considers zones of the
-- specified type
{ key = 'Z', mods = 'ALT', action = act.CopyMode { MoveForwardZoneOfType ='Output' }},
```
refs: https://github.com/wez/wezterm/issues/2346
Without the feature the build fails with:
--> src\escape\apc.rs:377:57
|
377 | let mut memory_info = MEMORY_BASIC_INFORMATION::default();
| ^^^^^^^ function or associated item not found in `MEMORY_BASIC_INFORMATION`
|
When `parse_first_as_vec` is parsing an OSC sequence (e.g.
`SetHyperlink`) that is terminated by the escaped form of ST (`ESC \`),
ensure that the ST sequence is included in the returned vector.
This is achieved by ensuring the VTParser has returned to the "ground"
state: i.e. the stored state after the `ESC` is processed is not enough
for `parse_first_as_vec` to terminate. We must also parse the `\` to
ensure that we return a complete span to the caller.
Fixes https://github.com/markbt/streampager/issues/57
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
