The click/movement related events are now "table driven" with
defaults contained in the InputMap object.
This gives the the potential to be configured from the config
file, but there is not glue in the config layer to enable
this yet.
This also does not include mouse wheel events.
introduce a helper enum that represents a mouse event in a more
ergnomic form and break the processing into two stages.
This will enable moving the mouse actions into assignable
actions in a later commit.
Now that the toml file support is removed, we can directly
express the key actions as enum variants so remove this
intermediate type and use the enum directly.
Adds some detection to see if the active keyboard layout has
AltGr, and if so, adjust our key mapping logic to accomodate it.
With this change, when using an ENG layout, I can use either left
or right alt-b/alt-f to move through words in wsl. When I switch
to DEU my left alt is still alt and my right alt causes the
Windows On-Screen keyboard to act as though AltGr is pressed.
I can then use the On-Screen keyboard to press the `<` key which
is to the left of the `Z` key on a German layout and have it produce
the `|` character.
refs: https://github.com/wez/wezterm/issues/185
This commit adds a simple example of nested widgets, which uncovered
an issue with respecting the layout positioning, and adds a secondary
screen buffer to make the widget render cycle more optimal:
```
cargo run --example widgets_nested --features widgets --release
```
refs: https://github.com/wez/wezterm/issues/171
I've been meaning to do this for a while: the intended purpose
is to use this to filter ansi escape sequences out of the prompt
in the shell pre-command hook.
* AppImage: Support looking for configuration in `WezTerm.AppImage.config` and
`WezTerm.AppImage.home` to support portable thumbdrive use of wezterm on
linux systems
* We now check the github releases section for updated stable releases and show
a simple UI to let you know about the update, with links to download/install
it. We don't automatically download the release: just make a small REST API
call to github. There is no data collection performed by the wezterm project
as part of this. We check once every 24 hours. You can set
`check_for_updates = false` in your config to disable this completely if
desired, or set `check_for_updates_interval_seconds` to an alternative update
interval.
* Added support for OSC 110-119 to reset dynamic colors, improving our support for Neovim.
* Change OSC rendering to use the long-form `ST` sequence `ESC \` rather than
the more convenient alternative `BEL` representation, which was not
recognized by Neovim when querying for color information.
* Fixed Shift-Tab key on X11 and Wayland
* WezTerm is now also available to Windows users via [Scoop](https://scoop.sh/)
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
We switched to using clipboard because of problems under XWayland.
These days we have much better native Wayland support and folks
should use that.
Test plan:
In one window:
```
echo "clipboard" | xclip -i -selection clipboard; echo "primary" | xclip -i -selection primary;
```
then start `wezterm` and press shfit-insert.
Prior to this change we'd always print `clipboard`.
After this change we'll print `primary`.
However, if you run:
```
WEZTERM_X11_PREFER_CLIPBOARD_OVER_PRIMARY=1 wezterm
```
then we'll use the old `clipboard` behavior.
neovim will try to force the window to resize after suspend/resume.
No other terminal allows this today, so rather than log it as an
unhandled event, explicitly ignore it.
This is a port of something I found when developing some changes
in watchman. When doing something like:
`some win32 command | wsl something`
That pipe doesn't look like a normal win32 pipe and we'd end up
treating it like a socket, but it isn't really a socket either.
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.
