When cycling through matches, set the current selection to the
matched range. This doesn't implicitly copy; it just marks the
range.
You can use the `Copy` key assignment to explicitly copy the
selection to the clipboard.
I'm sort of on the fence about implicit copying.
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
When installed by the installer, we add registry entries to configure
directory context entries in explorer.exe that enable "Open WezTerm
here" to function.
This works by running your default program with the current working
directory set to the one specified.
I plan to only enable this when installed by the installer so that
these can be deleted/updated by the installer later on.
If you want wezterm to run a different program by default, then
you can change the default_prog config in the wezterm configuration;
I don't plan on adding lot of context menu entries for this.
Note that attempting to open in the `C:\` root doesn't always seem
to work for me. I haven't had a chance to understand what's going
on there.
refs: https://github.com/wez/wezterm/issues/155
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.
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
