Previously we'd silently (well, we'd log to stderr) fall
back to the CPU renderer.
Let's instead pop up a config error window to make this
class of error more visible.
refs: #272
This commit teaches the config layer to distinguish between
explicitly configured fonts and automatic fallback fonts.
Font loading now maintains the set of loaded fonts. If after
loading from all configured sources a non-fallback font is
not present in the loaded set, wezterm will now pop up the
configuration error window to explain what is happening.
closes: #263
In this scenario:
```lua
local wezterm = require "wezterm"
return {
font_size = 12.0,
font_dirs = {"/home/wez/.fonts"},
font_locator = "ConfigDirsOnly",
font = wezterm.font_with_fallback({
-- this is an invalid font
"does not exist",
"Noto Color Emoji",
}),
}
```
we'd take the metrics from the emoji font and the cell size would
be crazy huge.
With this change we filter out "outliers" based on the approximate
pixel size for a font given its size and dpi. If a fallback position
is significantly larger or smaller than the theoretical size then
we skip it when considering the metrics.
The result of this is that with the above configuration we end up
with `{"Noto Color Emoji", "JetBrains Mono"}` as the font order;
most of the textual glyphs will render from `JetBrains Mono` but
the number glyphs prefer the `Noto Color Emoji` renditions which
are typically double width. While the terminal looks a bit
cartoonish as a result of that selection, the sizes are much more
reasonable compared to the screenshot in #263.
refs: #263
Moved the image and hyperlink portion of CellAttributes out
to a separate heap structure, saving 8 bytes per Cell
for the common case of no hyperlink and no image.
Replaces SmallVec with an internal TeenyString that only
occupies a single machine word and avoids heap allocation
in the common case on most architectures. This takes the
textual portion of Cell from 32 bytes to 8 bytes.
The nightly builds seem to often trip over each other when
uploading the source tarball from ubuntu20.
Restrict it to being built only on the appimage build (ubuntu16).
025732d00f introduced deferred
window creation; the creation would get scheduled into the
spawn queue and then get run again a few milliseconds later
on the main thread.
For reasons that I don't understand, returning to the scheduler
loop to flush or otherwise process messages causes a wayland
protocol error.
Adjusting the notify routine to dispatch immediately if we're
already on the mux thread seems to resolve this.
While looking at this, I cleaned up a destruction order issue
with the opengl state that was then causing a segfault on shutdown.
I also removed a bit of dead paint related code that doesn't
appear to be needed any more.
refs: #293
The mac builds started to fail with a crate resolution issue that I
can't reproduce locally shortly after I updated the cache action. Let's
tweak the cache key to see if that clears things up.
This will delay for the specified number of milliseconds.
This is an async function; it won't block the gui thread,
it will deschedule running the script and resume it once
the timeout has expired.
refs: #222
One of the updates in the past week made the reactor/async-io
stuff sensitive to the fork performed by daemonizing.
We can "simply" re-exec ourselves post-fork to resolve this.
Allows this:
```lua
local wezterm = require 'wezterm';
local io = require 'io';
local os = require 'os';
wezterm.on("trigger-vim-with-scrollback", function(window, pane)
-- Retrieve the current viewport's text.
-- Pass an optional number of lines (eg: 2000) to retrieve
-- that number of lines starting from the bottom of the viewport
local scrollback = pane:get_lines_as_text();
-- Create a temporary file to pass to vim
local name = os.tmpname();
local f = io.open(name, "w+");
f:write(scrollback);
f:flush();
f:close();
-- Open a new window running vim and tell it to open the file
window:perform_action(wezterm.action{SpawnCommandInNewWindow={
args={"vim", name}}
}, pane)
-- After vim is up and running we should remove the file,
-- but we can't do this right now as the window and processing
-- spawning are asynchronous and we'll probably delete the
-- file while vim is starting up :-/
-- os.remove(name);
end)
return {
keys = {
{key="E", mods="CTRL",
action=wezterm.action{EmitEvent="trigger-vim-with-scrollback"}},
}
}
```
refs: #222
This commit adds very basic first passes at representing the Pane
and GuiWindow types in lua script.
The `open-uri` event from 9397f2a2db
has been redefined to receive `(window, pane, uri)` parameters
instead of its prior very basic `uri` parameter.
A new key assignment `wezterm.action{EmitEvent="event-name"}` is
now available that allows a key binding assignment to emit an arbitrary
event, which in turn allows for triggering an arbitrary lua callback
in response to a key or mouse click.
`EmitEvent` passes the `(window, pane)` from the triggering window and
pane as parameters.
Here's a brief example:
```lua
local wezterm = require 'wezterm';
wezterm.on("my-thingy", function(window, pane)
local dims = pane:get_dimensions();
wezterm.log_error("did my thingy with window " .. window:window_id() ..
" pane " .. pane:pane_id() .. " " .. dims.cols .. "x" .. dims.viewport_rows);
window:perform_action("IncreaseFontSize", pane);
end)
return {
keys = {
{key="E", mods="CTRL", action=wezterm.action{EmitEvent="my-thingy"}},
}
}
```
refs: #223
refs: #225
This was broken by the changes in
aad493ab2a. The issue was that the
channel send didn't wakeup the receiver. I'm not sure why, and I tried
a couple of different async channel implementation.
Doing the simplistic solution here works reliably.
This builds on the new lua event handler plumbing added
in ccea650a93 to co-opt
the default URI opening action:
```lua
wezterm.on("open-uri", function(uri)
if uri:find("jira") then
wezterm.log_error("do something with jira")
wezterm.run_child_process({
"wezterm",
"start",
"--",
"jira",
"view",
extract_task_from_uri(uri)
})
-- prevent the default action from opening in a browser
return false
else
-- log but allow the uri to be opened in the browser
wezterm.log_error("clicken " .. uri)
end
end)
```
This doesn't allow exactly the sketched out option from
issue #223 to be implemented, but may be close enough
to be useful.
refs: #223
refs: #225
* `wezterm.on("event-name", func)`
* `wezterm.emit("event-name", "arg1", "arg2")`
`on` allows registering multiple functions.
`emit` will call each of the registered functions in turn, passing
a copy of the arguments. If a handler returns false, no additional
handlers are called and `emit` will return false. Otherwise,
once all the handlers have been called, `emit` will return true.
`emit` is capable of being called by async code.
These functions are available to the config layer, but nothing in
wezterm uses them at this time.
refs: #225
* Taught wezterm-mux-server how to `--daemonize` on windows
* Removed pty based command spawn used to spawn unix domain servers.
This was present because it was the only way to successfully spawn
wsl in the past. What I'm finding today is that it doesn't work
at all for me, generating an `0xc0000142` Application failed to
initialize error. A plain command builder spawn seems to work,
so that's what we're going with.
* Ensure that we put `.exe` on executable name on windows, otherwise
the spawn may fail.
* `Path::exists()` always returns false for unix domain sockets on
Windows, so unconditionally try to remove the socket before binding,
otherwise the bind will falsely fail, claiming that another process
is already bound.
The docs for mux will need to be updated to show how to revise them
for the new mux server invocation:
```lua
unix_domains = {
{
name = "wsl",
serve_command = {"wsl", "wezterm-mux-server", "--daemonize"}
},
}
```
