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.
https://github.com/AppImage/AppImageKit/issues/368 introduced a way
to maintain configuration alongside an AppImage file stored on a
flash drive:
```
wez@cube-localdomain /tmp/portable-wezterm
9:06 130 $ ls -al
total 8720
drwxrwxr-x. 4 wez wez 100 May 6 08:54 ./
drwxrwxrwt. 19 root root 580 May 6 09:05 ../
-rwxr-xr-x. 1 wez wez 8929256 May 6 08:59 WezTerm-20200505-090057-31c6155f-Fedora31.AppImage*
drwxrwxr-x. 3 wez wez 60 May 6 08:15 WezTerm-20200505-090057-31c6155f-Fedora31.AppImage.config/
drwxrwxr-x. 2 wez wez 40 May 6 08:54 WezTerm-20200505-090057-31c6155f-Fedora31.AppImage.home/
```
When launched and these `<IMAGE>.config` and/or `<IMAGE>.home` dirs
exist, the appimage machinery will redirect the HOME and XDG_CONFIG_DIR
env vars to point to those locations instead of the normal place.
We weren't respecting XDG_CONFIG_DIR (fixed in this commit), but we also
need to take care: we don't want to re-export those locations to
children of wezterm so we need to load those values and then clean
up the environment.
The real problem was an inconsistency in computing the tab bar
enablement state. This makes the math the same in both places
and re-enables the `hide_tab_bar_if_only_one_tab` option.
There's some discussion about terminal identification and
there's what looks to be some consensus for adopting these
two environment variables that were pioneered by Apple.
refs: https://github.com/mintty/mintty/issues/881
We need to gate with the config generation check as update_title
can be called during the configuration reloading process and
the tab bar state may not reflect the config until after the
config is reloaded!
refs: https://github.com/wez/wezterm/issues/173
Teach the window layer about window icons and implement the
plumbing for this on X11.
For Wayland there is no direct way to specify the icon; instead
the application ID is used to locate an appropriate .desktop filename.
We set the app id from the classname but that didn't match the installed
name for our desktop file which is namespaced under my domain, so change
the window class to match that and enable the window icon on Wayland.
refs: https://github.com/wez/wezterm/issues/172#issuecomment-619938047
On windows, prevent console subsystem processes spawned by
lua (such as the `wsl -l` example configuration) from momentarily
popping up and stealing the focus. This was happening too fast
to see in most cases, but could cause the wezterm window to momentarily
repaint its title bar with lose focus before regaining it.
This fixes an annoyance with the configuration error window;
previously we would spawn a new window for each error that
was discovered in the config, which cluttered up the screen
and felt irritating when iterating on the config file.
This commit reuses the connection status UI infra to make a
single persistent error log window.
This commit adds some helper functions that make it possible to
dynamically discover and add WSL distributions to the launcher
menu.
refs: https://github.com/wez/wezterm/issues/159
This restructures the LineEditor to allow the hosting application to
override key presses and apply custom edits to the editor buffer.
Methods for performing predefined actions and for accessing the line
buffer and cursor position have been provided/exposed to support this.
One consequence of this change is that the editor instance needs to be
passed through to the host trait impl and that means that the LineEditor
can no longer be generic over `Terminal`. Instead we now take `&mut dyn
Terminal` which was how the majority of non-example code was using it in
any case. This simplifies a bit of boilerplate in wezterm but adds an
extra line to the most basic examples.
This is unfortunately a bit of a muddy commit and I'm too lazy to split
it up.
* Removed `Position::NoChange`; use `Position::Relative(0)` instead
* Added missing cursor positioning cases in the terminfo renderer
* Taught line editor about the cursor position when the line spans
multiple physical lines
* Taught the Windows input layer to process escape sequences for eg:
the arrow keys when running with virtual terminal enabled.
* Removed the hack that under-reported the terminal width; the hack
was present to make some aspects of rendering with the native windows
console logic easier, but it was getting in the way of the line
editor. This may well break something, but it fixed up the line
editor :-/
cc: @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
This should allow some basic reasoning about how in sync we are with
the remote system.
The immediate application of this is to try to avoid wiggling the
text cursor when the predictive echo updates the position locally.
I need to push this in order to test it on my higher latency setup,
so I don't know if this is totally effective yet.
This is used to indicate timeout/retries during connection establishment
and also to count down to the automatic window close.
The UI will render a progress bar underneath the reason text to show
the passage of time, as well as counting down the provided duration.
Extends the "predictions" to allow for some basic cursor movement
via cursor keys and text deletion.
In addition, show predictions for pasted text.
refs: https://github.com/wez/wezterm/issues/127
This is a mosh-like feature, but not as sophisticated.
The goal is to reduce perceived latency by making a reasonable
guess about how the line where the cursor is located will change
in response to a key press.
At the moment the guess has some very basic heuristics:
* The key is an unmodified (no CTRL, ALT, SUPER) `char` value
* The line containing the cursor doesn't appear to be a
password prompt (using a very simple English specific test)
In those conditions, we'll update the local line cache and cursor
position with how we think the text will appear, but we set the
underline attribute (which is relatively rarely used) to make it clearer
that this is synthetic.
For low latency environments (eg: local network) the underline
rarely appears unless you are able to type very quickly.
I've yet to test this on a higher latency link, but think
this is good enough to land and build out so that I can test
that scenario with my work systems.
refs: https://github.com/wez/wezterm/issues/127
I made this unbounded originally because I wanted to do something
smarter around config reloading. I'm still too lazy to make it
do that, but do recognize that we should have some limit on the
line cache size, so we just pick the value of the scrollback
size at the time we started.
This used to be effectively the same thing, but now that the launcher
menu allows attaching to other domains, it is best if the hotkey
matches the behavior of the + button on the tab bar and uses the
domain of the current tab instead.
* Increase timeout from 2 to 10 seconds, giving you more time to read it
* Make the timeout work even if the UI object is unexpectedly destroyed
* When attaching via the launcher, don't reconnect when the server
version mismatches the client version.
This adjusts the mux protocol so that we can tell when a remote tab
has been closed; previously we couldn't distinguish between an IO
error and the tab going away.
Similarly, if the remote mux has shut down (which we detect via an EOF),
then we won't try to reconnect and will proceed to detach that domain.
Hadn't noticed this until just now because the systems I've been
using have all had a pretty similar filesystem layout.
This commit avoids a failure to spawn a child process when the
desired directory doesn't exist locally.
This is accessible by right-clicking on the `+` button in the tab bar
and switches to an overlay offering options to spawn tabs and attach
domains.
The intent is to allow the configuration file to expand this list of
options, and on Windows, to auto-populate with the various combinations
of `cmd`, `powershell`, `elevated` and available `wsl` instances, but
for the moment the main value of this feature is the ability to attach
domains that were not set to connect automatically at startup.
This makes things more convenient when launching wezterm via the
gui: it is awkward to have to set up shortcuts that run
`wezterm connect foo`, or to type in the full path to `wezterm` when
you might want to run that manually.
Now you can double-click the icon and right-click the `+` and attach
the domain. (cc: @rjwalsh)
The launcher is a good candidate for being implemented on top of
native context menus where available... but we don't have any
such API plumbed through the `window` crate, so all platforms
get the wonderful terminal based overlay menu right now.
refs: https://github.com/wez/wezterm/issues/159
This commit tackles a couple of things in related areas:
Makes it possible to reference the KeyAssignment type directly from the
KeyAction action type. Previously, due to limitations in how TOML is
serialized, the enum values could be used here; while the compiler would allow
it, it is impossible to construct a TOML value for this sort of enum. Now that
we have lua we have more flexibility in the table type and this is unblocked.
In practical terms this means that we can do away with the janky `arg` field
and just use the `action` field directly, which also means that we can do away
with a whole extra enum that duplicates just the enum variants and makes
maintenance easier!
Adds `wezterm.action` to lua which helps to construct these enum variants. The
helper is used like this in the `.wezterm.lua` file:
```lua
local wezterm = require 'wezterm';
return {
keys = {
{key="{", mods="SHIFT|CTRL", action=wezterm.action{ActivateTabRelative=-1}},
{key="}", mods="SHIFT|CTRL", action=wezterm.action{ActivateTabRelative=1}},
}
}
```
the above creates values like `KeyAssignment::ActivateTabRelative(-1)`
in a not totally awful syntax.
On top of this, which was the main reason for doing this work, this
commit adds two new variants to KeyAssignment that are accessible
on from lua (because of the TOML limitations mentioned above);
`SpawnCommandInNewWindow` and `SpawnCommandInNewTab` that take a
`SpawnCommand` struct as their parameter. These actions are
conceptually similar to the existing `SpawnTab` key assignment
but allow specifying the program to be run as well as its cwd
and environment.
For example, this key assignment spawns `top` in a new window:
```lua
{key="y", mods="CMD", action=wezterm.action{SpawnCommandInNewWindow={
args={"top"}
}}},
```
The intent is to use this as a building block for saved/canned
commands.
refs: https://github.com/wez/wezterm/issues/159
implementing the `ToLua` and `FromLua` traits allows `create_function`
to automatically apply the appropriate conversions to the parameters
and return values in a callback function.
That makes it possible (and nicer!) to write properly typed callbacks.
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.
