This commit teaches the config about SerialDomains, and the mux
layer about constructing a SerialDomain, then changes the GUI
layer to use those pieces to set up `wezterm serial`.
A new `serial_ports` config is added, and the GUI layer knows how
to apply it to the set of domains in the mux.
The result of this is that you can now define a domain for each
serial port and spawn a serial connection into a new tab or window
in your running wezterm gui instance.
It's a tremendous PITA for the user to do this at the system level on a
mac, where it is sorely needed. This commit allows raising to a desired
minimum level, but won't decrease from an already larger soft limit.
refs: https://github.com/wez/wezterm/discussions/3353
Add a link to regex syntax supported in wezterm, so eg. we have a way to know that perl character class '\c' is not supported and instead we can use the ascii equivalent [:cntrl:]
* Update ssh_backend.md
* Update normalize_output_to_unicode_nfc.md
* Update strikethrough_position.md
* Update underline_position.md
* Update underline_thickness.md
* Fix lua config docs titles to be formatted as inline code
* Mention how suggested alphabet for quick select is choosen
* Mention update-status and update-right-status for status_update_interval
* Fix docs for all keyassignments to be formatted as inline code
* Fix Lua object index titles
* Fix titles of `wezterm.*` module index pages
* Fix title of `Color` object & `wezterm.color` functions
We reduce titles from h2 to h1 because mkdocs defaults the page title to
the page file name if no h1 header is found.
* Unify title of all object methods
* Add index page for Gui events
Nudge new users towards using this style:
```lua
local config = {}
config.color_scheme = 'Batman'
return config
```
and surface how to write lua modules closer to the main section
on config files. In that lua modules section, nudge towards using
a convention similar to that of the plugin spec described in
this commit: e4ae8a844d
I don't recall changing it to copy to the primary selection only, and
it doesn't feel like it is something I would want anyway, and I think
it generally makes things annoying for all but power users
https://fosstodon.org/@trentskunk@mstdn.social/109808345817367266
Threads through a GuiPosition from mux window creation to allow it to be
used when the corresponding gui window is created.
SpawnCommand now has an optional position field to use for that purpose.
```lua
wezterm.mux.spawn_window {
position = {
x = 10,
y = 300,
-- Optional origin to use for x and y.
-- Possible values:
-- * "ScreenCoordinateSystem" (this is the default)
-- * "MainScreen" (the primary or main screen)
-- * "ActiveScreen" (whichever screen hosts the active/focused window)
-- * {Named="HDMI-1"} - uses a screen by name. See wezterm.gui.screens()
-- origin = "ScreenCoordinateSystem"
},
}
```
refs: https://github.com/wez/wezterm/issues/2976
The motivation here was to remove some similar but not quite the same
logic that existed for starting up when using `wezterm connect`.
Now `wezterm connect DOMAIN` is implemented as `wezterm start --domain
DOMAIN --attach --always-new-process` and a little extra hand-wave to
ensure that the default domain is set correctly.
The startup events have been refactored a bit; a new gui-attached
event is emitted after attaching and starting any default programs
in the selected domain at startup.
That event can be used to maximize windows and so on, if desired.
The gui-attached event is independent of the startup command and fires
for `wezterm connect`, which `gui-startup` did not (and could not) do.
config_builder helps to make issues more visible/useful in the case
where you may have typod a config option, or otherwise assigned
an incorrect value.
