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.
We were uploading all the packages as `wezterm-20220419.075038-r0.apk`
regardless of the alpine version.
Also, what we upload to the nightly release must not include a version
number, otherwise the release will hold an unbounded number of versions!
* add update-alternatives hooks for deb packages
Tested on ubuntu 20.04/21.10 and Linux Mint 20.3
* Apply suggestions from code review
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
checkout seems to be failing for ubuntu 20 recently:
```
Deleting the contents of '/__w/wezterm/wezterm'
Initializing the repository
/usr/bin/git init /__w/wezterm/wezterm
Initialized empty Git repository in /__w/wezterm/wezterm/.git/
/usr/bin/git remote add origin https://github.com/wez/wezterm
Error: fatal: unsafe repository ('/__w/wezterm/wezterm' is owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory /__w/wezterm/wezterm
Error: The process '/usr/bin/git' failed with exit code 128
```
Try reverting this as a workaround.
I wanted to use the Target::Pipe feature of env_logger so that we could
log to a log file as well as stderr, but it just doesn't work
(https://github.com/env-logger-rs/env_logger/issues/208).
Since we were already composing over the top of the logger in order
to capture data for our ringlog, this commit embraces that and makes
our logger responsible for both stderr and log file printing.
Thankfully, we can use the filter parsing code from env_logger to
avoid having to get too crazy with this.
Logs are stored in the runtime directory and look something like:
/run/user/1000/wezterm/wezterm-gui-log-596324.txt
Logs are collected on all platforms.
There isn't currently a thing to clean up logs.
The keys section was way too big; this splits it up into more
manageable pieces, adds a nice flow chart to show how key events
are processed and adds an example of using the new key tables feature.
This is a bit more compact and easier to edit.
A downside is that the search engine highlight can break the diagram and
cause it to emit a syntax error.
The centos8 builds have been failing today, and it appears to
be because https://www.centos.org/centos-linux-eol/ happened
about 3 years early and the URLs in the image are hard-broken.
https://forums.centos.org/viewtopic.php?f=54&t=78708 has some
info on re-pointing them to a vault subdomain.
The "right" thing to do is to migrate to centos 8 stream, but
I don't see a centos stream docker image from centos.
This commit attempts the manual migration steps to stream.
Let's see how this goes.
This commit switches back to wezterm-icon.svg as the source of
the icon, but modifies it:
* Removed mac style title bar + window manipulation icons
* Increases the corner radius
* Adjusts the text position and size
This makes it somewhere between the original and one of the alternate
icons in 98b71cbfb6
I chose to modify the original source as it didn't have padding
baked into the svg file, and I didn't feel like wrestling with
the contributed svg in inkscape to remove it.
This commit adds plumbing to support mapping the process tree to
lua objects which in turn allows a new `mux-is-process-stateful`
event to be defined by the user for finer control over closing
prompt behavior.
refs: #1412
`gh` is pre-installed in native runners only; when we build in a
container, we need to install it for ourselves.
This commit drops support for building on centos7 as it is a PITA
to get this working there.
I lost a few hours over the weekend because the GH release uploads
are flakey and the action I was using doesn't internally perform
retries. I had to manually delete the failed uploads from the release
and then re-trigger the builds across several platforms, several times
for both of the releases I pushed this weekend :-/
This commit speculatively switches over to using the GH cli in the
hopes that the error reporting is better, and also because it is
simpler to externally drive a retry loop.
Let's see how this goes.
I added this originally to see if the templating was working correctly.
With the recent changes to make it a cask, it's now much longer and
obscures some of the other more valuable output, so remove it.
Previously, we used `git describe --tags` to produce a version number
for non-released builds derived from the most recent tag + some info
such as the number of commits since that tag and then `g{HASH}`.
That always confuses people because the date portion at the front
looks old (it is typically the previous release) and the hash at
the end has that `g` in it.
This commit simplifies both the tag name used when making a release
and the computed version number take the date/time from the current
commit, and then append the hash. That way the version number always
corresponds to a commit.
This scheme doesn't help detect situations where the commit is
dirty, but I don't think the old one would have helped with that
either.
* Make alphabet and patterns configurable
* add docs
* Enhance scrollback search to support regex captures so that
searching for eg: `fo(o)` will select the last `o` in `foo`.
refs: https://github.com/wez/wezterm/issues/732
CI got broken by the termwiz release. This commit teaches the
various `git describe --tags` calls to filter to the wezterm
tags which all start with the year. We're match `20*` which should
be good for the next 79 years.
I've removed the vergen dependency as there was no way to teach it
to do the equivalent matching, and it wasn't a terrible burden
to just inline the git describe call anyway.
This commit reduces the cron schedule for nightly builds down from
hourly and to actually nightly (at ~3am).
The push-to-master flow now triggers effectively the same thing at push
time, so if anything, this will reduce the latency of the continuous
package build and deploy.
The push-to-master flow will now skip builds if it changes only the
docs.
I started this a while ago; it's pretty time consuming to produce
accessible and usable documentation for this sort of stuff, so
this isn't yet complete, but in the interest of avoiding additional
bit-rot, let's get this up.
refs: https://github.com/wez/wezterm/issues/257
This persuades the CI to install both the arm and intel flavors
of the rust toolchain on macOS, and the deploy script to generate
a universal binary.
* need big sur to build for M1
* Use cross-compilation compatible mlua from my fork for now
