The cursor colors in gogh weren't imported quite right; this
fixes things up so that we use the background color together
with the cursor color from the scheme.
refs: https://github.com/wez/wezterm/issues/4257
Neither of these understand image protocols, and both are
an additional processing layer between the application and
wezterm.
This commit detects and wraps OSC sequences in tmux's passthru
sequence so that the data is passed on to wezterm rather than
elided from the data stream.
For image protocols in both tmux and conpty, work a little
smarter and explicitly move the cursor position to the same
location that wezterm would move it to. That prevents the
display from being as mangled by tmux/conpty due to a diverging
understanding of the cursor position.
The logic isn't perfect, and can result in the x-coordinate
being incorrect, and this won't work with the new --position
argument either in its current state, without adding a lot
of complexity to deal with scrolling and relative and absolute
positioning handling.
To facilitate that, a new termwiz Terminal trait method has
been added to probe the terminal name, version, cell and pixel
dimensions. It's not pretty.
refs: https://github.com/wez/wezterm/issues/3624
refs: https://github.com/wez/wezterm/issues/3716
- Removes closures and function calls for types that implement default:
```rust
// Change
let _my_str = get_str().unwrap_or(String::new);
// To
let _my_str = get_str().unwrap_or_default();
```
- Uses the `.cloned()/.copied()` methods where possible
- Use function pointer instead of simple closure
May improve performace, as closures generate more code, and this might
unlock some inlining opportunities.
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.
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.
Adjust importer to read directly from the source .itermcolors
files in the upstream repo. Extract some author information
from the comments in those files.
All data is now fetched (and cached!) via relatively minimal
http requests rather than requiring a git repo locally.
Also search for .yml files in base16 repos; found another
couple of schemes this way.
The toml files under assets/colors are no longer read by
anything in the repo. I plan to remove them, but since the
docs reference them as examples, I will first ensure that
there are docs and tooling that explains how to write and
share your own scheme files.
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.
