`#XYZ` is parsed by `XParseColor` and it requires that the
hex nybbles are present in multiples of 3, and it has different
padding rules for under- or over-specified nybbles.
refs: https://github.com/wez/wezterm/issues/2209
This commit adjusts the config loading code so that we can return
information about the paths the should be watched for a subsequent
reload even in the more common error cases.
refs: #1174
ee5206db50 attempted to fix this by
replacing all DynValue::Null values with a special null userdata.
However, a consequence of that is that it broke:
```
window:get_config_overrides() or {}
```
because a userdata is always true, even if it represents a null value.
This commit fixes that case by being selective with the userdata usage:
we only use it when converting the value portion of a table key/value
pair.
refs: #2177
refs: #2200
This is a bit of an unsatisfactory commit... the bulk of it is
augmenting our calls into XCB to ensure that we check the status of each
request; the idea was that doing so would highlight the source of the
bad drawable error that is being surfaced in #2198, but after doing
that, it still doesn't highlight the offending call.
My conclusion is that either something in MESA/EGL or the IME is
generating calls that we cannot see into and that one of those is
referencing the window id that we just destroyed.
The resolution then is a bit gross: instead of destroying the window
when we need to close it, we first unmap it to remove it from the
screen, then after 2 seconds we destroy it.
refs: https://github.com/wez/wezterm/issues/2198
We need the mux window builder to notify in order for the ConnectionUI
to show up, but we wouldn't trigger the notify (which happens on drop)
until we'd awaited the connection ui completing password auth.
Force it to drop earlier to unblock.
refs: https://github.com/wez/wezterm/issues/2194
Allow iterating all windows at the mux layer.
windows allow iterating tabs.
Tabs allow iterating panes.
Versions of iteration that report additional information (like index,
active and positioning) are also added.
Panes can now reference their containing tab and window objects.
Tabs can now reference their containing window object.
refs: https://github.com/wez/wezterm/issues/1598 (sort of)
refs: https://github.com/wez/wezterm/issues/225
Previously, the mux layer had no internal understanding of titles other
than the Pane::get_title method to return state from a pane.
Users have asked for ways to explicitly set titles on windows and tabs,
so this commit is a step towards that.
The mux window and tab objects now store a title string.
The terminal layer now emits Alert::WindowTitleChanged when the window
title is changed via eg: OSC 0 or OSC 2.
The mux layer will respond to Alert::WindowTitleChanged by resolving the
window that corresponds to the source pane and amending its title.
The MuxWindow and MuxTab objects now provide accessor methods for the
title.
TabInformation (as used by format-tab-title and format-window-title) now
exposes the underlying window_id as well as tab_title and window_title.
The tab title can be changed via the lua MuxTab type, but there is not
currently an escape sequence associated with this.
The defaults for format-tab-title and format-window-title don't
currently consider these new title strings.
refs: https://github.com/wez/wezterm/issues/1598
The issue here was that the from_dynamic impl derived for a struct
that was inlined in an enum didn't respect the the field properties
defined for the struct.
Refactor to reuse the same field_info helper used by the struct
code.
Update docs to clarify what the default value actually is.
refs: https://github.com/wez/wezterm/issues/2179
In #2177 we found that one of the examples that tries to use
the default initialization was failing. The root cause is that
we were constructing a value like:
`{ExtendSelectionToMouseCursor=nil}`
which is effectively the same as:
`{}`
but that has no information on the enum variant name.
This commit avoids mapping DynValue::Null to LuaValue::Nil
and instead uses a light user data nullptr value.
That allows the structure to round trip correctly.
refs: #2177
In https://github.com/wez/wezterm/issues/2170 a config like this was
used:
```lua
return {
keys = {
{key="e", ...},
copy_Mode = {
{key="a", ...}
}
}
}
```
instead of the intended:
```lua
return {
keys = {
{key="e", ...},
},
key_tables={
copy_Mode = {
{key="a", ...}
}
},
}
```
This commit makes an attempt at detecting when non-numeric, or sparse
numeric, keys are used for an array style table and generates an error.
The error isn't ideal, but it at least indicates that something is
wrong:
```
Configuration Error: Error converting lua value returned by script
/tmp/whoops.lua to Config struct: error converting Lua table to Config
(error converting Lua table to value (while processing "keys": error
converting Lua string to numeric array index (Unexpected key "copy_mode"
for array style table)))
```
refs: #2170
dc728b3895 introduced some non-determinism
by mutating the global TARGETS list.
The result is, depending on iteration order, the generated jobs
may inherit the env from earlier jobs.
Notably, if the tag job inherit the schedule reason from a continuous
job, they'll upload assets with an incorrect filename.
This commit restores the determinism by forcing each iteration
of the generation loop to make a deep copy of the statically
defined information in TARGETS.
While we're at it, ensure that the list of env vars is sorted
to avoid non-determinism there as well.
refs: https://github.com/wez/wezterm/issues/2176
