The .deb package registers that script as the alternative for
a terminal emulator in the hope that various "open terminal here..."
functions in other tools will use that to detect wezterm and run
thing in the cwd.
refs: https://github.com/wez/wezterm/issues/2103
so have the arg parser raise an error if used without it:
```
; wezterm cli spawn --workspace foo
error: The following required arguments were not provided:
--new-window
USAGE:
wezterm cli spawn --new-window --workspace <WORKSPACE>
For more information try --help
```
refs: https://github.com/wez/wezterm/issues/2248#issuecomment-1192119746
Need to explicitly pop it in front of the tab text layer so that
the button is physically rendered on top of the tab title.
refs: https://github.com/wez/wezterm/issues/2269
Various color schemes have been duplicated as they have been added to
different scheme collections. They don't always have identical names
(eg: some remove spaces) and sometimes they have very different names
(eg: _bash vs. nightfox, or Miu vs. Blazer).
We already detected duplicates from different collections but previously
we would omit those dupes.
This commit allows us to track those duplicates by recording their
aliases.
When we write out our data, we only include "interesting" alias names;
those where the name isn't trivially identical.
Some scheme collections (eg: iterm2 color schemes) have duplicates
(eg: zenbones and zenbones_light are identical) and we have previously
shipped with both of those names, so we special case to emit dupes
for which we have prior version information in order to avoid
breaking backwards compatibility for our users.
In the doc generation we can generate links to the aliases if we
included them, but also note about the other names and how we don't
include them. That is so that someone searching the docs for say
"_bash" can discover that it is actually a duplicate of "nightfox" and
use nightfox instead.
This allows the hook to choose how to handle eg: `wezterm start -- top`.
Previously, if you had implemented this event you would essentially lose
the ability to specify a command that you wanted to launch.
refs: https://github.com/wez/wezterm/issues/284
I needed this while swinging through to the new color scheme data stuff,
but I don't need it any more, and it causes problems with external toml
files.
This is necessary for applications spawned via wezterm to be able to
generate apple events.
wezterm already had the text for the authorization prompt in its plist,
but because it was code signed with the default set of entitlements,
macOS didn't bother to prompt.
This commit introduces an explicit set of entitlements and uses those
when signing the executable.
I test this by manually codesigning on my laptop and confirmed that I
could run bbedit from inside wezterm.
I can't directly test the CI version of that flow on my laptop as it may
destroy my keychain if I got something wrong.
We'll have to see if the CI generated build works out!
refs: https://github.com/wez/wezterm/issues/2242
h/t to https://github.com/microsoft/vscode/issues/119787 for
clearly documenting what was needed.
Right now the initial x11 appearance retrieval uses the specific
connection interface, which completely circumvents the already existing
more complete implementation in x_and_wayland.rs.
The latter implementation is strictly better, because it first attempts
getting the appearance from the XDG desktop portal and then falls back
to the X11 interface.
Before this patch there was a very weird issue for folks using the OS
system dark mode with the following config snippet:
```
color_scheme = scheme_for_appearance(wezterm.gui.get_appearance())
```
The color_scheme on startup would be correct, but there would be a very
weird problem where sometimes wezterm ignores the first time that the
portal notifies about an appearance update.
The source of the bug was an inconsistent retrieval of the appearance
setting:
- The Lua API used the XDG desktop portal
- The internal appearance used the X11 specific connection at startup
For example due to this, the internal appearance variable could have
stored "Dark" from the X11 connection, but the actual appearance from
the XDG desktop portal was "Light".
If then the XDG desktop portal changes to "Dark", the
appearance_changed() method would dismiss the update because
self.appearance was already "Dark".
It is only after that, that the internal inconsistency would have been
solved and following appearance changes would succeed and update the
colorscheme correctly.
To fix this problem, we now use the portal directly in both the x11 and
wayland connections, which is consistent with the Lua
wezterm.gui.get_appearance() API.
refs: #2258
