Hi,
I encountered an error while trying to upgrade Wezterm to a newer nightly build on MacOS using the previous brew command. The error message was:
“Error: Cask wezterm-nightly exists in multiple taps:
homebrew/cask-versions/wezterm-nightly
wez/wezterm/wezterm-nightly”
To resolve this issue temporarily, I modified the shell script to use the "wez/wezterm/wezterm-nightly" tap. However, I wanted to check if it's preferable to use the "homebrew/cask-versions/wezterm-nightly" tap instead. Please let me know your thoughts on this.
Thanks!
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
If there are no windows, clicking on the dock icon will spawn a new
window.
Requires that `quit_when_all_windows_are_closed=false`
refs: https://github.com/wez/wezterm/issues/3057
We need to manually convert to string, as the default ToDynamic
impl encodes the underlying bits value from the bitfield and
that doesn't round trip with the try_from String impl
Brief usage notes here:
```lua
local wezterm = require 'wezterm'
local a_plugin = wezterm.plugin.require "https://github.com/owner/repo"
local config = wezterm.config_builder()
a_plugin.apply_to_config(config)
return config
```
The referenced repo is expected to have a `plugin/init.lua` file,
and by convention, return a module that exports an `apply_to_config`
function that accepts at least a config builder parameter, but may
pass other parameters, or a lua table with a `config` field that maps
to a config build parameter.
`wezterm.plugin.require` will clone the repo if it doesn't already
exist and store it in the runtime dir under `plugins/NAME` where
`NAME` is derived from the repo URL. Once cloned, the repo is
NOT automatically updated.
Only HTTP (or local filesystem) repos are allowed for the git URL;
we cannot currently use ssh for this due to conflicting version
requirements that I'll take a look at later.
`wezterm.plugin.require` will then perform `require "NAME"`,
and since the default `package.path` now includes the appropriate
location from the runtime dir, the module should load.
Two other functions are available:
`wezterm.plugin.list()` will list the plugin repos.
`wezterm.plugin.update_all()` will attempt to fast-forward or `pull
--rebase` each of the repos it finds. It doesn't currently do anything
proactive to reload the configuration afterwards; the user will need to
do that themselves.
Rust 1.67, released today, is a bit more particular about the layout
of the memory used in TeenyString and segfaults in the test suite.
On closer inspection, our Drop impl was casting to Vec<u8> instead of
TeenyStringHeap and the fault was freeing bogus memory within that
region.
Fixing the cast to the correct type resolves the issue.
