The problem was that the pane resizes got optimized away because the
tab size doesn't change as part of the zoom operation.
We don't need to run the full resize logic for unzoom though, just
need to re-apply the size to the unzoomed pane.
We don't have a convenient way to do that, so we re-apply the sizes
to all of the panes in the tab.
refs: https://github.com/wez/wezterm/issues/157#issuecomment-701173561
These serve two purposes:
* Provide a consistent default font for new installations,
that happens to show off ligature and color emoji support
out of the box.
* Provide a reasonable fallback in case the configuration is broken
Both fonts are distributed under the terms of the OFL 1.1.
refs: https://github.com/wez/wezterm/issues/263
Repro steps were:
* Split horizontal
* Resize y to be shorter; size shrinks to zero
* Resize y to be taller; size grows to u16::max and then overflows
The return statement was missing; probably a copy-n-paste-o as
the equivalent logic for the x size adjustment had it.
closes: https://github.com/wez/wezterm/issues/276
If a pane is killed via mux manipulation, the reader didn't have
a way to notice this and could keep reading the data in a loop.
This commit adds an atomic boolean to signal back from the mux
to the reader.
This isn't perfect; the reader thread may still be blocked in
read until the underlying process is really killed.
This uses a similar approach to that used by tmux; when resizing,
a size delta is computed in each axis and that value is distributed
across the splits in that dimension.
For a small resize by 1 cell this tends to bias towards adjusting
the top/left node.
For a large resize (eg: maximizing/restoring) the distribution tends
to share across the splits in that dimension, effectively scaling
them approximately proportionally, more or less preserving the relative
scale of the splits.
refs: https://github.com/wez/wezterm/issues/157#issuecomment-699672914
`wezterm.action{ExtendSelectionToMouseCursor=nil}` doesn't produce an
`ExtendSelectionToMouseCursor(None)` value because a table value of
`nil` is equivalent to that key not being present and lua sees just
an empty table.
Instead we need to accept `ExtendSelectionToMouseCursor={}` a valid
way to indicate an `Option::None` which is what this commit does.
Due to weirdness that I haven't had a chance to run down, passing
that value through `wezterm.action` doesn't produce the intended
value, so I'm adjusting the docs to show to specify an alternative
syntax for this as part of this commit.
refs: https://github.com/wez/wezterm/issues/282
wezterm splits pastes into chunks of 1KB. If that chunk was in
the middle of a UTF8 multibyte sequence, the rust string library
would panic.
This commit rounds the chunk size up to the next character
boundary.
closes: https://github.com/wez/wezterm/issues/281
This config reproduces the issue:
```lua
local wezterm = require "wezterm"
return {
font_size = 12.0,
font_dirs = {"fonts"}, -- relative to this config file
font_locator = "ConfigDirsOnly",
font = wezterm.font_with_fallback({
-- this is an invalid font
"does not exist",
-- this is a valid font, with only symbols
"Font Awesome 5 Free Solid",
}),
}
```
the existing protections were a bit simplistic, so now we have a
dedicated error type for this case and that stops fallback processing
from recursing.
closes: https://github.com/wez/wezterm/issues/279
This removes the active pane from the current tab, causing the
tab to close if it was the last remaining pane in the tab.
```lua
{key="W", mods="CTRL", action="CloseActivePane"},
```
refs: https://github.com/wez/wezterm/issues/157
This commit introduces a new `leader` configuration setting
that acts as a modal modifier key.
If leader is specified then pressing that key combination
will enable a virtual LEADER modifier.
While LEADER is active, only defined key assignments that include
LEADER in the `mods` mask will be recognized. Other keypresses
will be swallowed and NOT passed through to the terminal.
LEADER stays active until a keypress is registered (whether it
matches a key binding or not), or until it has been active for
the duration specified by `timeout_milliseconds`, at which point
it will automatically cancel itself.
Here's an example configuration using LEADER:
```lua
local wezterm = require 'wezterm';
return {
-- timeout_milliseconds defaults to 1000 and can be omitted
leader = { key="a", mods="CTRL", timeout_milliseconds=1000 },
keys = {
{key="|", mods="LEADER|SHIFT", action=wezterm.action{SplitHorizontal={domain="CurrentPaneDomain"}}},
-- Send "CTRL-A" to the terminal when pressing CTRL-A, CTRL-A
{key="a", mods="LEADER|CTRL", action=wezterm.action{SendString="\x01"}},
}
}
```
refs: https://github.com/wez/wezterm/issues/274
Seems that you need to have read everything you want before you
call waitpid, otherwise the pending data seems to be snipped and
prevented from being read.
closes: https://github.com/wez/wezterm/issues/187
This commit provides the heart of the split functionality.
It adds a couple of key assignments (that are not finalized)
for splitting the active pane horizontally or vertically.
Clicking in a pane will activate it.
Selection is constrained to the active pane.
Resizing a window will grow/shrink the right/bottom side of a split.
The scrollbar applies to the active split.
There's not yet a way to resize a split at all.
There's not yet a key assignment for changing the active split.
The software renderer doesn't know how to render the splits correctly.
refs: https://github.com/wez/wezterm/issues/157
This expands the data model for Tab so that it can record a binary
tree of panes; this allows for conceptually splitting a Pane either
horizontally or vertically.
None of the other layers know about this concept yet.
refs: https://github.com/wez/wezterm/issues/157
This adds an extra level of indirection to the Mux model;
previously we allowed for Windows to contain an ordered
collection of Tabs, where each Tab represented some kind
of pty.
This change effectively renames the existing Tab trait to Pane
and introduces a new Tab container, so the new model is that
a Window contains an ordered collection of Tabs, and each Tab
can have a single optional Pane.
refs: https://github.com/wez/wezterm/issues/157
Attempt to recover in the case where we cannot re-allocate
our vertex buffers; try to restore the prior dimensions
and resize the OS window to match.
refs: https://github.com/wez/wezterm/issues/265
Rather than scanning directories and reading in ~230 files on startup,
do the scan at build time so that we're parsing from memory rather
than local storage.
This should shave a bit of time off the startup, although I
haven't measured this, and I've only run this on a remote
linux system thus far.
refs: https://github.com/wez/wezterm/issues/264
Need to use the subsecond microsecond value, rather than the total
microsecond value, otherwise `select(2)` will yield EINVAL.
The wezterm changes show where this error was bubbling up
and breaking the tls client code.
