Rather than having each call site add a window to the mux and then
call the front end to spawn a window, make the mux emit a signal
advising of a window spawn, and have the front end subscribe to
that signal.
There was a flaw in processing the built-ins; because we searched
the built-ins as part of the font dir step we'd satisfy matching
the default fallback from the in-memory fonts and it would accidentally
take precedence over the fonts provided by the system font locator.
This commit makes an explicit additional (final) step to search
the built in fonts.
refs: #263
When confirmation is enabled, a really basic overlay is
rendered over the top of the tab to request confirmation.
The default key assignment for CloseCurrentTab now
has confirmation enabled.
```lua
action=wezterm.action{CloseCurrentTab={confirm=true}}
action=wezterm.action{CloseCurrentTab={confirm=false}}
```
refs: https://github.com/wez/wezterm/issues/157
refs: https://github.com/wez/wezterm/issues/280
When confirmation is enabled, a really basic overlay is
rendered over the top of the pane to request confirmation.
```lua
action=wezterm.action{CloseCurrentPane={confirm=true}}
action=wezterm.action{CloseCurrentPane={confirm=false}}
```
refs: https://github.com/wez/wezterm/issues/157
refs: https://github.com/wez/wezterm/issues/280
This is a bit of a switch-up, see this comment for more background:
refs: https://github.com/wez/wezterm/issues/265#issuecomment-701882933
This commit:
* Adds a pre-compiled mesa3d opengl32.dll replacement
* The mesa dll is deployed to `<appdir>/mesa/opengl32.dll` which by
default is ignored.
* When the frontend is set to `Software` then the `mesa` directory
is added to the dll search path, causing the llvmpipe renderer
to be enabled.
* The old software renderer implementation is available using the
`OldSoftware` frontend name
I'm not a huge fan of the subdirectory for the opengl32.dll, but
I couldn't get it to work under a different dll name; the code
thought that everything was initialized, but the window just rendered
a white rectangle.
If we've failed to initialize EGL, try setting `LIBGL_ALWAYS_SOFTWARE=true`
in the environment and make another pass at initialization in the hope
that it brings up something usable.
This commit only impacts linux systems at the time of writing.
I've made the line that logs the GL implementation information
have `error` level again, because it is more convenient for me
even if it isn't technically an error.
refs: https://github.com/wez/wezterm/issues/272
(but isn't the true fix; this is just trying to make the consequences
of that problem less. I would like to get that fixed correctly)
refs: https://github.com/wez/wezterm/issues/265#issuecomment-701882933
(which discusses what I think the end state should be)
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
