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.
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"}
},
}
```
This version no longer generates invalid CA certificates and
allows TLS connections using the internal PKI to advance
further. Still need to debug an early disconnect.
kindof a lot going on in this commit, unintentionally:
* Need the lua context set to be moved into the config crate
otherwise configs cannot be parsed by the server and we end
up with the default configs
* Make the server use smol for async io
* Drop the use of the daemonize crate, which I had forked anyway.
Just inline our own tighter daemonize module
* Improve daemon spawning synchronization, however, it still needs
work for windows to avoid blocking forever where we don't do
daemonizing.
This commit adds support for left/right margins and has been
tested against esctest, with a final status of:
```
309 tests passed, 239 known bugs
```
"known bugs" also includes unimplemented features; we have a
similar degree as iTerm2.
As of this commit, we now report as a vt520ish machine to DA1.
I confess to not having read enough of the relevant docs
to know whether this is totally righteous.
This corrects an issue where the mode byte of the DCS sequence was
discarded from the DcsHook, making it impossible to know what sequence
is being activated.
So far this hasn't come up as these sequences are relatively rare,
but in looking at sixel parsing I noticed the error.
This commit doesn't do anything specific to scrollback though!
It moves the implementation of the TermWizTermTab away from
a directly manipulated Surface and over to using the term::Terminal,
making the renderer look more like the one used by the local tab
and domain implementation.
As a side effect of doing this, we get scrollback management
for free.
refs: https://github.com/wez/wezterm/issues/201
Since the last release we've migrated from failure -> anyhow,
added more functions to the command builder, improved windows
support and have compatibility with the `smol` crate.
refs: https://github.com/wez/wezterm/issues/166
This commit adds some plumbing that will use the github API to
probe the currently released version of wezterm, and if it is
newer than the running version, show a window with some release
information and links to the changelog and download page.
The checks can be disabled in the config (but require a restart
to take effect!) and default to checking every 24 hours.
If running an AppImage on linux, links directly to the appimage
download. In the future I'd like to have the download button
use zsync to apply the update to the local image.
This commit changes the behavior on Windows:
* If $TERM is set and the `terminfo` crate is able to
successfully initialize and locate a terminfo database (this also
requires that $TERMINFO be set in the environment), then we'll
use the `TerminfoRenderer` instead of the `WindowsConsoleRenderer`
* If $TERM is set to `xterm-256color` and no terminfo database was
found, use our modern compiled-in copy (look in the `termwiz/data/`
directory for the source and compiled version of this) and use
the `TerminfoRenderer`.
* Otherwise use the `WindowsConsoleRenderer`.
In practice, this allows termwiz apps to opt in to features such as
true color support on Windows 10 build 1903 an later by setting their
`TERM=xterm-256color`. This happens to be the default behavior when
`ssh`ing in to a windows host via `wezterm`.
You can see the truecolor mode get applied by running this example:
```
cargo run --example widgets_basic --features widgets
```
with TERM set as above the background region that is painted by the app
will be a blueish/purplish color, but with it unset or set to something
invalid, it will fall back to black.
I'd like to eventually make termwiz assume the equivalent configuration
to `TERM=xterm-256color` by default on Windows 10 build 1903 and later,
but it's worth getting some feedback on how this works for clients such
as `streampager`.
cc: @quark-zju and @markbt
The predictive echo feels pretty reasonable, but if the connection
is having problems and we're showing the tardiness indicator, the
echo can give the impression that your input is going to get processed.
That may not be (usually is not!) the case.
This commit makes it a bit more visually distinctive that something
isn't right by greying out the color palette in that case.
refs: https://github.com/wez/wezterm/issues/127
Make a reasonable suggestion to the user based on similarity with
possible field names, but don't error out.
This facilitates evolving the configuration over time, and makes
the config more forgiving of typos.
This allows for slightly more fancy configuration in the future, but for
now it is rather simple: your lua script returns a configuration struct
with the same shape as that from the TOML file.
A `wezterm` module is provided to the script that provides some
constants to help understand the environment in which wezterm
is running.
I want to add some helpers that make setting up the fonts feel less
weird (lots of nesting in the data model makes this weird).
The ability to conditionally construct configuration is powerful
and helps to address the broader request in
refs: https://github.com/wez/wezterm/issues/152
An example config looks like this:
```lua
local wezterm = require 'wezterm';
print(wezterm.config_dir);
print(wezterm.executable_dir);
wezterm.log_error("w00t! running " .. wezterm.version
.. " on " .. wezterm.target_triple .. " " .. wezterm.home_dir);
return {
enable_scroll_bar = true,
enable_tab_bar = true,
ratelimit_output_bytes_per_second = 400000,
scrollback_lines = 350000,
font_dirs = {".dotfiles/fonts"},
window_padding = {
left = 2,
bottom = 2,
},
font = {
font = {{
family = "Operator Mono SSm Lig Medium",
}},
},
unix_domains = {
{
name = "unix",
}
},
ssh_domains = {
{
name = "localhost",
remote_address = "localhost",
username = "wez",
},
},
tls_clients = {
{
name = "cubetls",
remote_address = "cube-localdomain:8080",
bootstrap_via_ssh = "cube-localdomain",
},
},
tls_servers = {
{
bind_address = "192.168.1.8:8080",
},
},
hyperlink_rules = {
{
regex = "\\b\\w+://(?:[\\w.-]+)\\.[a-z]{2,15}\\S*\\b",
format = "$0",
},
},
font_rules= {
{
italic = true,
font = {
font = {{
family = "Operator Mono SSm Lig Medium Italic",
}}
},
},
{
italic = true,
intensity = "Bold",
font = {
font = {{
family = "Operator Mono SSm Lig Book Italic",
}}
},
},
{
intensity = "Bold",
font = {
foreground = "tomato",
font = {{
family = "Operator Mono SSm Lig Bold",
}}
},
},
{
intensity = "Half",
font = {
font = {{
family = "Operator Mono SSm Lig Light",
}}
},
},
},
}
```
That version has the ability to use SSH agent forwarding.
This commit doesn't enable that functionality, it's just updating
the version and adjusting for changes in the upstream.
Embed rgb.txt and parse it on the fly to produce the list of colors.
This list is a superset of palette's SVG color list.
refs: https://github.com/wez/wezterm/pull/144
The default values are 3 lines. With this change, scrolling speed now seems
similar to other programs like cmd.exe. Before this change it feels too slow.
I got to the bottom of the hang on startup when trying to connect
to the multiplexer on windows and it was because of the change
in 367a44fb96 to try to drain the pollable
channel.
This mapped to ReadFile on windows which always tries to fill the buffer
even if it is a socket under the covers.
348421b010
teaches filedescriptor to use the recv/send if the filedescriptor is
really a socket and that resolves the hang.
Matching against the current dir when it includes a host and a
path seems like a handy way to automate selecting appropriate
theme/color/profile settings, so I'd like to make sure that
we have the full URL content available for that.
Refs: https://github.com/wez/wezterm/issues/115
Refs: https://github.com/wez/wezterm/issues/117
This mostly works, but has a cache invalidation issue wrt.
passing invalidated rows from the server to the client...
sometimes.
However, scrollback is cached on demand and selection works.
We need to build in release mode so targets are cacheable.
GH has a limit of 400MB per cache blob and we're at 750MB with
the debug build. Slim it down a bit.
The cache wants to hash the Cargo.lock file so I've removed that
from the ignore file and added it to the repo. This might cause
an error for users checking out the repo after this change is
pushed; removing the local Cargo.lock should resolve that.
