Previously we'd return the Url string. Now we provide a Url
object that provides access to the various elements of the Url.
This will cause slightly breakage for folks that were treating
it as a string in their status event handlers, for example.
The docs have been updated to show how to run with both this
new Url object and also continue to run on older versions of
wezterm.
They now also show how to manually percent decode the url
for older versions of wezterm.
refs: https://github.com/wez/wezterm/discussions/4157
refs: https://github.com/wez/wezterm/issues/4000
Run `ci/flatpak.sh` to build a flatpak of just the gui.
Run it via flatpak run org.wezfurlong.wezterm
refs: https://github.com/wez/wezterm/issues/2229
Thanks to: @Imxset21
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 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.
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
Profiling showed that set_font_size was a hotspot. While there was
caching of the size info at the shaper layer, it was also needed in
the raster layer, so move it into the raster layer from the shaper
layer.
refs: #353
This includes a script to generate a screenshot from a wezterm
running the default config under X11.
It expects the iTerm2-Color-Schemes to be checked out alongside
the wezterm repo as it uses the dynamic color schemes scripts
to activate the schemes one by one and capture the display.
This is untested beyond eyeballing the locally generated file.
Will need to make a couple of tags to test this for sure.
refs: https://github.com/wez/wezterm/issues/209
We need to build in release mode so targets are cacheable.
GH has a limit of 400MB per cache blob and we're at 750MB with
the debug build. Slim it down a bit.
The cache wants to hash the Cargo.lock file so I've removed that
from the ignore file and added it to the repo. This might cause
an error for users checking out the repo after this change is
pushed; removing the local Cargo.lock should resolve that.
This reverts commit 8dcf3cb21e.
My experience with even getting in the door with snaps was sub-par.
The submission/review process seems under specified and under staffed.
The tools for producing snaps were also rather broken in the case
that your PATH doesn't match a blessed configuration. This was
hard to discover and expensive to iterate on.
My conclusion is that snaps are not for me.
