This commit is a bit noisy because it also meant flipping the key map
code from using the termwiz input types to the window input types, which
I thought I'd done some time ago, but clearly didn't.
This commit allows defining key assignments in terms of the underlying
operating system raw codes, if provided by the relevant layer in the
window crate (currently, only X11/Wayland).
The raw codes are inherently OS/Machine/Hardware dependent; they are the
rawest value that we have available and there is no meaningful
understanding that we can perform in code to understand what that key
is.
One useful property of the raw code is that, because it hasn't gone
through any OS level keymapping processing, its value reflects its
physical position on the keyboard, allowing you to map keys by position
rather than by value. That's useful if you use software to implement
eg: DVORAK or COLEMAK but want your muscle memory to kick in for some of
your key bindings.
New config option:
`debug_key_events = true` will cause wezterm to log an "error" to stderr
each time you press a key and show the details in the key event:
```
2020-12-06T21:23:10.313Z ERROR wezterm_gui::gui::termwindow > key_event KeyEvent { key: Char('@'), modifiers: SHIFT | CTRL, raw_key: None, raw_modifiers: SHIFT | CTRL, raw_code: Some(11), repeat_count: 1, key_is_down: true }
```
This is useful if you want to figure out the `raw_code` for a key in your
setup.
In your config, you can use this information to setup new key bindings.
The motivating example for me is that because `raw_key` (the unmodified
equivalent of `key`) is `None`, the built-in `CTRL-SHIFT-1` key
assignment doesn't function for me on Linux, but I can now "fix" this in
my local configuration, taking care to make it linux specific:
```lua
local wezterm = require 'wezterm';
local keys = {}
if wezterm.target_triple == "x86_64-unknown-linux-gnu" then
local tab_no = 0
-- raw codes 10 through 19 correspond to the number key 1-9 positions
-- on my keyboard on my linux system. They may be different on
-- your system!
for i = 10, 20 do
table.insert(keys, {
key="raw:"..tostring(i),
mods="CTRL|SHIFT",
action=wezterm.action{ActivateTab=tab_no},
})
tab_no = tab_no + 1
end
end
return {
keys = keys,
}
```
Notice that the key assignment accepts encoding a raw key code using
a value like `key="raw:11"` to indicate that you want a `raw_code` of
`11` to match your key assignment. The `raw_modifiers` portion of
the `KeyEvent` is used together with the `raw_code` when deciding
the key assignment.
cc: @bew
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
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.
