When the search overlay is active, pressing ctrl-r cycles through
the different pattern matching modes; currently case sensitive and
case insensitive, but shortly to add regex.
The search ui now also indicates the current mode.
The default opens up search with an empty pattern in case sensitive
string matching mode.
The revised structure will allow doing things like eg: defining a key
assignment that searches for git hashes by regex.
If set to true, then none of the default key or mouse bindings,
respectively, will be registered in the GUI, leaving it up to
the user to provide all key assignments.
The goal at the window layer is to preserve enough useful information
for other layers. In this specific circumstance on macos we'd like
to be able know both that eg: ALT-1 was pressed and that ALT-1 composes
to a different unmodified sequence and then allow the user's key
binding assignment to potentially match on both.
We sort of allowed for this, but didn't separate out the modifier keys.
This commit adds a `raw_modifiers` concept to the underlying event
struct so that we can carry both the raw key and modifier information
as well as the composed key and modifier information.
In the scenario above, we want the raw key/modifier tuple to be ALT-1
but the composed key/modifier to be eg: unmodified `¡` in my english
keymap.
refs: https://github.com/wez/wezterm/issues/158
This allows for: `wezterm start --cwd c:/` to spawn the default
program explicitly in the `c:/` location, rather than the default
behavior for determining the cwd.
refs: https://github.com/wez/wezterm/issues/155
Bound to CMD-K and CTRL+SHIFT-K by default. This also functions
while the output is filling up (eg: `find /` and hit the key binding
to keep pruning the scrollback).
closes: https://github.com/wez/wezterm/issues/194
The root cause of this was that the dirtyness test always considered
the display to be changed and was clearing the selection to ensure
visual consistency.
This was actually a stealthy bug where we'd use more CPU and memory
than we strictly needed.
closes: https://github.com/wez/wezterm/issues/189
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.
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.
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.
