Three issues:
* The initial connect would leave the dpi assigned to 0, resulting
in incorrect scaling when using imgcat until the window was resized
and the correct dpi was passed up.
* On resize, we'd only compare the row/col count and not notice changes
in pixel dimensions/dpi
* On the server side, when processing a resize and recomputing
the tab size, we would omit the pixel dimensions and leave
the resulting tabs and panes with 0 dimensions, breaking imgcat
because it thought the window was 0x0.
refs: https://github.com/wez/wezterm/issues/3366
This fixes a surprising interaction between copy mode and the
command palette, but is also the root cause of another issue
with CharSelect mode.
refs: https://github.com/wez/wezterm/issues/2947
Given an assignment like this:
```
{
key = "b",
mods = "ALT",
action = wezterm.action.SplitPane {
direction = 'Right',
command = {
label = 'Bash Right',
args = {'/usr/bin/bash' }
}
}
}
```
we should show the label from the command in the palette.
That's what this commit enables.
If there is no label, but the arguments are set, then the
arguments will be shown instead.
refs: #3252
This commit causes the mux to generate a PaneFocused notification
when the active pane is changed.
The mux server will forward that as a unilateral PDU to connected
clients.
The clientpane implementation will handle that by applying the
same state to the local mux.
refs: #2863
* Translate from File to EncodedFile as needed
* Adopt blob leases in the mux server
* Fix an issue where the first image sent by the mux server would
be replaced on the client by its background image, if configured.
Removed the ImageData::id field to resolve this: you should use
the hash field instead to identify and disambiguate images.
Bumped the termwiz API version because this is conceptually
a breaking change to the API
refs: https://github.com/wez/wezterm/issues/3343
Weird behavior from macos; the command line:
`wezterm start vim hello`
would result in macos requesting `vim` and `hello` be opened
as "documents" which would route each of those to the .command
script handling flow and spawn a window for each; running:
`vim ; exit` in one
`hello ; exit` in another
in addition to the normal handling of that command line.
This commit resolves this by igoring document opening
requests until after the application is fully launched.
I tested this by trying to open a .command script with
this new build and verified that that continued to work.
refs: #3340
This one was a bit weird because something appeared to be a bit
non-deterministic. With this config:
```lua
local wezterm = require 'wezterm'
return {
window_frame = {
border_left_width = '1cell',
border_right_width = '1cell',
border_bottom_height = '0.5cell',
border_top_height = '0.5cell',
border_left_color = '#444',
border_right_color = '#444',
border_bottom_color = '#444',
border_top_color = '#444',
},
window_padding = {
left = '1.5cell',
right = '1.5cell',
top = '0.5cell',
bottom = '0.5cell',
},
}
```
starting wezterm could result in a terminal that reported either 23 or
24 lines. I got 24 when running the build from da7e29df but usually
23 when running a build out of my repo.
Looking closely, the issue is that the initial window size didn't
account for the configured border size, and that we'd subsequently
fix that up when we later do a resize fixup after creating the window.
This commit refactors the window border logic so that it can be
used prior to having fully constructed the terminal window and then
uses that to fixup the initial computed dimensions.
I also noticed with this config that increasing the font size
with CTRL-+ could also result in an inconsistency between the displayed
terminal size and the pty size we set in the kernel: it was missing
the border adjustment as well, so I added it in there.
refs: #3333
Really, this is adjusting the logical line breaking behavior, or the
lack thereof.
The situation is this: conpty can decided to reinterpret and flush
large sections of its buffer as a continuous stream of unbroken
characters with no breaks when it repaints the full screen.
When we receive such an update, we see it as one long logical line,
and when we subsequently select multiple lines we can run into the
maximum logical line length and insert invalid synthetic line breaks
into the data that we send to the clipboard.
This commit adjusts the wrapping logic at the time that we receive
the text so that we don't tag the line as a logical line continuation
if:
* The alt screen is active. Full screen apps will re-render on resize
anyway, and we don't reflow long lines on resize either for the same
reasons
* If we are talking to ConPTY:
* If the last character in the line is not alphanumeric or
punctuation (in other words: it doesn't look plausibly like
text that should be a line continuation).
refs: #3278
refs: #3177
* 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
Fixes this:
```
> wezterm.GLOBAL.foo = {"bar", "baz"}
> wezterm.GLOBAL.foo
[
"bar",
"baz",
]
> #wezterm.GLOBAL.foo
runtime error: [string "repl"]:1: attempt to get length of a userdata value (field 'foo')
stack traceback:
[string "repl"]:1: in main chunk
>
```
and allows this:
```
> for k, v in pairs(wezterm.GLOBAL.foo) do print(k, v) ; end
```
Pull in the enhanced scheme that includes wezterm metadata and colors.
Co-authored-by: Thomas Croft <103956335+thomascft@users.noreply.github.com>
closes: https://github.com/wez/wezterm/pull/3208
GH actions has been awful slow and bogged down recently,
getting in the way of work that is more important.
This commit removes a variety of alpine builds (which are
not widely used by wezterm users), and the eldest fedora
version to free up some resources.
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
Input data:
\e_Ga=T,f=32,s=10,v=22,c=1,r=1,m=1\e\\e_Gm=1;/xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T//P=\e\\e_Gm=1;/xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T//P=\e\\e_Gm=0\e\
There were two issues in handling this:
* We expected there to be `;payload` in the first transmission packet,
but there wasn't one, so we ignored it as ill-formed.
* The standard base64 decoder in the rust ecosystem is super strict
and rejects the "sloppy" python base64 encoder output that isn't
strictly conformant with the RFC. We need to jump through some
hoops to get it to relax and accept the input.
refs: https://github.com/wez/wezterm/issues/2716
Continuing from the previous commit, this shifts:
* In-memory data -> temporary file
* Image decoding -> background thread
The background thread asynchronously decodes frames and
sends them to the render thread via a bounded channel.
While decoding frames, it writes them, uncompressed, to
a scratch file so that when the animation loops, it is
a very cheap operation to rewind and pull that data
from the file, without having to burn CPU to re-decode
the data from the start.
Memory usage is bounded to 4 uncompressed frames while
decoding, then 3 uncompressed frames (triple buffered)
while looping over the rest.
However, disk usage is N uncompressed frames.
refs: https://github.com/wez/wezterm/issues/3263
Need to use a newer version of libssh-rs that can report this state,
as the underlying libssh doesn't fold it into the process exit
status.
refs: https://github.com/wez/wezterm/issues/3095
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
Previously, when resizing a tab, we'd unzoom it, recompute the resize
deltas and adjust every pane's non-zoomed position and re-zoom the
original pane.
When the alt screen is active, wezterm doesn't reflow resized lines,
and there a number of situations where the only effective change to
the line was updating a seqno; the content of those panes doesn't
actually update until the application(s) attached to the PTY
receive SIGWINCH from the kernel.
Since we were resizing the zoomed pane twice in quick succession
we could double-tap SIGWINCH and the application might coalesce
and process only one of the resize events.
The result of that was that we might see the state from either
the first or second resize event and then not get any other updates
until the application repainted itself.
This commit re-structures the resize behavior around zooms so that
we only resize the zoomed pane. When unzooming we'll fixup the
no-zoomed sizes for the whole tab. That means that we need to
store the pre-zoom size in order to correctly calculate those
sizes for the case where a pane was zoomed, the tab resized, and
then the pane was unzoomed again.
refs: https://github.com/wez/wezterm/issues/3068
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
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.
The tcgetpgrp call appears to have high variance in latency, ranging
from 200-700us on my system.
If you have 10 tabs and mouse over the tab bar, that's around 7ms
spent per frame just figuring out the foreground process; that doesn't
include actually extracting the process executable or current working
directory paths.
This was exacerbated by the mouse move events triggering a tab bar
recompute on every pixel of mouse movement.
This commit takes the following steps to resolve this:
* We now only re-compute the tab bar when the UI item is changed by
a mouse movement
* A simple single-item cache is now used on unix that allows the caller
to proceed quickly with stale-but-probably-still-mostly-accurate data
while queuing up an update to a background thread which can absorb
the latency.
The result of this is that hovering over several tabs in quick
succession no longer takes a noticeable length of time to render the
hover, but the consequence is that the contents of a given tab may be
stale by 300-400ms.
I think that trade-off is worth while.
We already have a similar trade-off on Windows, although we don't
yet do the updates in a different thread on Windows. Perhaps in
a follow up commit?
refs: https://github.com/wez/wezterm/issues/2991
On my mac, depending the config, I noticed that modals didn't always
render immediately; force a window invalidation after assigning to
encourage them to do so.
Add the key to enter Copy Mode to the table. It may be repetitive, but it
makes the table a useful cheatsheet.
Document `y`, it was undocumented.
Use kbd tag. Capitalize all keys with modifiers for consistency. Use mixed
case names for the modifiers. Use `+` for key combinations.
In https://github.com/wez/wezterm/issues/2932 the user desired to have
brightened text without the boldness, as they were accustomed to that
behavior in a couple of other terminal emulators.
This commit changes the `bold_brightens_ansi_colors` from a simple
boolean to a tristate that allows for not changing the brightness,
changing the brightness, and changing the brightness while adjusting
the boldness down to normal levels.
boolean values are accepted for backwards compatibility.
```
thread 'main' panicked at 'Error in Surface::configure: Both `Surface` width and height must be non-zero. Wait to recreate the `Surface` until the window has non-zero area.', C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.14.0\src\backend\direct.rs:274:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
refs: https://github.com/wez/wezterm/issues/2881
We have to manually connect for this to work well across both
underlying libraries. libssh in particular doesn't support it
at all.
refs: https://github.com/wez/wezterm/issues/2893
