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.
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.
Currently implemented on X11 only, this function returns information
about the geometry of the screen(s).
This is taken from the same source of information we use for the
`--position` CLI argument to `wezterm start`.
```
> wezterm.window.screens()
{
"by_name": {
"DisplayPort-1": {
"height": 2160,
"name": "DisplayPort-1",
"width": 3840,
"x": 0,
"y": 0,
},
},
"main": {
"height": 2160,
"name": "DisplayPort-1",
"width": 3840,
"x": 0,
"y": 0,
},
"origin_x": 0,
"origin_y": 0,
"virtual_height": 2160,
"virtual_width": 3840,
}
```
Using the newly exposed-to-lua mux apis, you may now run some lua code
at GUI startup and/or mux startup, just prior to any default windows
being created.
If you happen to spawn any panes as a result of this, wezterm will
skip creating the default program.
```lua
local wezterm = require 'wezterm'
local mux = wezterm.mux
-- This produces a window split horizontally into three equal parts
wezterm.on("gui-startup", function()
wezterm.log_info("doing gui startup")
local tab, pane, window = mux.spawn_window{}
mux.split_pane(pane, {size=0.3})
mux.split_pane(pane, {size=0.5})
end)
wezterm.on("mux-startup", function()
wezterm.log_info("doing mux startup")
local tab, pane, window = mux.spawn_window{}
mux.split_pane(pane, {size=0.5, direction="Top"})
end)
return {
unix_domains = {
{name="unix"}
},
}
```
refs: #674
refs: #1949
The intent is to expose Mux related functions to lua, so `wezterm.mux`
will be that module table.
In order to test this out in the debug overlay, I realized that the
overlay was running functions in a different thread and didn't have
access to the mux, so this commit also tweaks the debug overlay repl to
execute the input in the main thread.
The result is that it is now possible to do
`wezterm.mux.active_workspace()` in the debug overlay to print the
active workspace name.
More functions will follow.
refs: https://github.com/wez/wezterm/issues/225
Main thing to note here is that the open crate has deprecated
open::that_in_background, but made open::that non-blocking.
I think this is OK, but I'm a little cagey about what will
happen with this on Windows. We may need to spawn our own
thread for this if things go awry.
This allows moving past a number of outdated deps, but importantly,
allows updating miow to a version that has the correct memory layout
for SocketAddr, and satisfies a dependabot alert.
This appeases some dependabot warnings regarding the use of
an old version of parking_lot that has some unsoundness issues.
ratelimit_meter is frozen and is succeeded by governor which has
a mostly similar API.
The hope here is that the nvidia-specific resize issue might have
a workaround if it is emitting some other events that we were
previously not listening for.
This commit optionally enables the Present extension and listens
for its version of CONFIGURE_NOTIFY, routing it through the same
logic as the base CONFIGURE_NOTIFY event.
On my AMD hardware under Gnome, I see something like:
```
18:04:26.476 TRACE window::os::x11::window > Present::ConfigureNotify: width 1168 -> 1180, height 858 -> 873, dpi 124.7998046875 -> 124.7998046875
18:04:26.478 TRACE window::os::x11::window > Ignoring X::ConfigureNotify (1180x873 dpi=124.7998046875) because width,height,dpi are unchanged
```
with the Present event firing before the X event.
Let's see how this goes.
refs: #2063
refs: #1992
My windows build didn't work this morning, complaining:
; cargo build
Updating crates.io index
error: failed to select a version for the requirement `libgit2-sys = "^0.13.4"`
candidate versions found which didn't match: 0.13.2+1.4.2, 0.13.1+1.4.2, 0.13.0+1.4.1, ...
location searched: crates.io index
required by package `git2 v0.14.4`
... which satisfies dependency `git2 = "^0.14"` (locked to 0.14.4) of package `config v0.1.0 (C:\Users\wez\wez-personal\wezterm\config)`
... which satisfies path dependency `config` (locked to 0.1.0) of package `codec v0.1.0 (C:\Users\wez\wez-personal\wezterm\codec)`
... which satisfies path dependency `codec` (locked to 0.1.0) of package `wezterm v0.1.0 (C:\Users\wez\wez-personal\wezterm\wezterm)`
The cargo update downgraded the dep, but looking at crates.io the
requested revs look ok. Something is fishy.
I upgraded rust and ran cargo update again to get back on the
same git rev, so now this commit captures the other things
that changed.
Avoid using serde for mapping between Lua and Rust for the `Config`
struct.
This improves the build speed of the config crate by 2x; it goes down
from 30 seconds to 9 seconds on my 5950x.
This cleans up the `cargo audit` output on linux because the `clipboard`
crate (which hasn't been updated in 3 years) depends on xcb=0.8.2
which is flagged by cargo audit.
We don't use `clipboard` on any platform except macos
This commit switches to the `clipboard_macos` crate; that appears to
use a copy and paste of the macos specific code from the `clipboard`
crate, so this shouldn't have any change in functionality.
refs: https://github.com/wez/wezterm/issues/1952
