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
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 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.
Record the version in which we first saw a color scheme.
For schemes from iterm2-color-schemes, we just assume that
we've had them forever as it isn't easy to reverse engineer
that metadata.
Everything else is tagged as 'nightly builds only' and I'll update
that to match the version number in the next release.
Newly discovered items will be added with 'nightly builds only'
from this point onwards.
Moved the gradient function into the color module, but kept an alias
under the old name.
Gradients now return color objects.
Converting colors to string now uses rgba format when alpha is not 100%.
wezterm.color.parse() returns a color object that can be assigned in the
wezterm color config, and that can be used to adjust hue, saturation and
lightness, as well as calculate harmonizing colors (complements, triads,
squares) from the RGB/HSL color wheel.
This commit expands the toml file definition to include
metadata for the origin url, author and name.
A new sync utility fills out that metadata when it pulls from the iterm2
color schemes repo.
The utility also pulls down the scheme data json maintained by
the Gogh project: https://gogh-co.github.io/Gogh/ and converts
it to wezterm's format.
About 50% of Gogh overlaps with iterm2; we take the iterm2 versions
of those schemes by default because the iterm2 data has more info
about things like cursor and selection colors.
The sync utility is responsible for compiling the de-duplicated
set of scheme data into a form that is used by wezterm and its
docs.
I've wanted to avoid checking in all the screenshot pics as the png
files change every time I run the generation script, and it bloats
the repo over time.
This commit changes the doc generation step to use the asciinema
web player with the equivalent contents.
Really, it's only a smallish step to go from this to just emitting
the html directly in the doc pages, but I think I might use
the player for some examples in the future.
I think this is still a fine step for now in any case.
While comparing this with the existing screenshots, I noticed the
the Alabaster screen shot png has the wrong color for its rightmost
column: there's an issue in wezterm in parsing the dynamic color
escapes that causes it to pick up the wrong color.
Loading the scheme by name has the correct color and matches
how it is shown as of this commit.
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.
