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.
Not sure why this only really showed up with Wayland, because the
issue was that the computed tab bar height ended up being 1 or 2
pixels shorter than the area we had allotted.
This commit resolves it by forcing the height to match, and
then aligning the content to the bottom of that region to avoid
having an undesirable line under the tab.
refs: #1256
An ExecDomain is a variation on WslDomain with the key difference
being that you can control how to map the command that would be
executed.
The idea is that the user can define eg: a domain for a docker
container, or a domain that chooses to run every command in its
own cgroup.
The example below shows a really crappy implementation as a
demonstration:
```
local wezterm = require 'wezterm'
return {
exec_domains = {
-- Commands executed in the woot domain have "WOOT" echoed
-- first and are then run via bash.
-- `cmd` is a SpawnCommand
wezterm.exec_domain("woot", function(cmd)
if cmd.args then
cmd.args = {
"bash",
"-c",
"echo WOOT && " .. wezterm.shell_join_args(cmd.args)
}
end
-- you must return the SpawnCommand that will be run
return cmd
end),
},
default_domain = "woot",
}
```
This commit unfortunately does more than should go into a single
commit, but I'm a bit too lazy to wrangle splitting it up.
* Reverts the nil/null stuff from #2177 and makes the
`ExtendSelectionToMouseCursor` parameter mandatory to dodge
a whole load of urgh around nil in table values. That is
necessary because SpawnCommand uses optional fields and the
userdata proxy was making that a PITA.
* Adds some shell quoting helper functions
* Adds ExecDomain itself, which is really just a way to
to run a callback to fixup the command that will be run.
That command is converted to a SpawnCommand for the callback
to process in lua and return an adjusted version of it,
then converted back to a command builder for execution.
refs: https://github.com/wez/wezterm/issues/1776
You can start a window in full screen mode using something like:
```lua
local wezterm = require 'wezterm'
local mux = wezterm.mux
wezterm.on("gui-startup", function()
local tab, pane, window = mux.spawn_window{}
window:gui_window():toggle_fullscreen()
end)
return {
}
```
refs: #177
refs: #284
`#XYZ` is parsed by `XParseColor` and it requires that the
hex nybbles are present in multiples of 3, and it has different
padding rules for under- or over-specified nybbles.
refs: https://github.com/wez/wezterm/issues/2209
This commit adjusts the config loading code so that we can return
information about the paths the should be watched for a subsequent
reload even in the more common error cases.
refs: #1174
We need the mux window builder to notify in order for the ConnectionUI
to show up, but we wouldn't trigger the notify (which happens on drop)
until we'd awaited the connection ui completing password auth.
Force it to drop earlier to unblock.
refs: https://github.com/wez/wezterm/issues/2194
Allow iterating all windows at the mux layer.
windows allow iterating tabs.
Tabs allow iterating panes.
Versions of iteration that report additional information (like index,
active and positioning) are also added.
Panes can now reference their containing tab and window objects.
Tabs can now reference their containing window object.
refs: https://github.com/wez/wezterm/issues/1598 (sort of)
refs: https://github.com/wez/wezterm/issues/225
Previously, the mux layer had no internal understanding of titles other
than the Pane::get_title method to return state from a pane.
Users have asked for ways to explicitly set titles on windows and tabs,
so this commit is a step towards that.
The mux window and tab objects now store a title string.
The terminal layer now emits Alert::WindowTitleChanged when the window
title is changed via eg: OSC 0 or OSC 2.
The mux layer will respond to Alert::WindowTitleChanged by resolving the
window that corresponds to the source pane and amending its title.
The MuxWindow and MuxTab objects now provide accessor methods for the
title.
TabInformation (as used by format-tab-title and format-window-title) now
exposes the underlying window_id as well as tab_title and window_title.
The tab title can be changed via the lua MuxTab type, but there is not
currently an escape sequence associated with this.
The defaults for format-tab-title and format-window-title don't
currently consider these new title strings.
refs: https://github.com/wez/wezterm/issues/1598
The issue here was that the from_dynamic impl derived for a struct
that was inlined in an enum didn't respect the the field properties
defined for the struct.
Refactor to reuse the same field_info helper used by the struct
code.
Update docs to clarify what the default value actually is.
refs: https://github.com/wez/wezterm/issues/2179
Update copymode.md: description of `O` key assignment
"only in Rectangular mode" is not correct anymore as at the
end of PR #2150, handling of `O` was changed to also work in
non-Rectangular modes.
This commit adds more trace logging around selection
related events.
That tracing uncovered a situation, when multiple wezterm windows within
the same process were involved, where one window didn't receive a
selection-clear event notification.
Since Window::get_clipboard trusted our local understand of the
clipboard contents, it would return those until the selection was
changed in that window.
This commit changes that code to always ask the X server for the
selection. It makes pasting slightly slower, but should always produce
consistent results.
refs: https://github.com/wez/wezterm/issues/2110
- Add regex that captures URLs with IP addresses as hosts.
- Removed redundant non-capturing parentheses from the first regex.
Mirrored the change to default_hyperlink_rules().
- Switched all but the first example to use literal strings for
regex (more readable).
This enables tentative support for https://sw.kovidgoyal.net/kitty/keyboard-protocol
It's only been lightly tested with the notcurses-input program and
eyeballed against a few random keypresses in kitty running
`printf "\x1b[=11u" ; od -c`
I tried with neovim, but it doesn't seem like the version available
in Fedora 36 supports this yet.
refs: https://github.com/wez/wezterm/issues/1141
Adds a configuration option, `focus_change_repaint_delay` to allow customisation of the delay added in 9b6329b454.
The default delay remains 100ms, and can be disabled by setting it to `0`, if the workaround is not required on the user's system.
refs: #2063
refs: #1992
The heart of the issue is that `sudo -i` sets the cwd to the homedir
of the root user, and that isn't accessible to the regular unprivileged
user, and cannot be set as the cwd for the newly spawned panes/tabs.
A secondary issue is that it is hard to see what the error is without
improved diagnostics.
So this improves the diagnostics, and then changes the existence
check that we were doing for local domain spawns to try to read the
directory instead.
refs: https://github.com/wez/wezterm/issues/2120
`wezterm.pad_righ` in the example should be `wezterm.pad_right`.
There's another problem, shared with the pad_left page, that `"o "` is rendered in the HTML with just one space, collapsing the two spaces to one, which is very misleading given what the example for this function does. It needs to be in a `<pre>` tag rather than just a `<code>` tag, but I don't know how to fix that from markdown.
