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
I noticed that the opensuse rpms didn't show up in the latest release,
and traced it to the spec file not setting anything in the filename
to distinguish the rpm files.
This commit replaces the redhat-ish short suffix with one of our
own derived from the os info.
subst-release-info.py will need to be updated to reflect this
change, but I want to see what names are produced for the various
platforms first.
Previously, trying to do something like `foo = "bar"` in the debug
overlay wouldn't succeed, because we were always trying to wrap
the line inside `return {line}`, which allowed for only expressions
to be used.
Now we also allow a fully formed statement to be used, which means
that that kind of assignment can be performed in the repl, making
it a bit more convenient to try stuff out.
refs: https://github.com/wez/wezterm/issues/1238
This avoids a confusing situation where we'd not bother to resolve
a font for a given codepoint for say bold text if we had previously
resolved it for normal text.
This hashset would be more useful if we maintained a mapping of
codepoint to font at that layer, but we don't.
The simplest thing to do for this is to allow the search to continue
and succeed.
refs: https://github.com/wez/wezterm/issues/2158
refs: https://github.com/wez/wezterm/issues/1913
