-
-
Notifications
You must be signed in to change notification settings - Fork 757
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lua: Add wezterm.action_callback
to help define key callbacks
#1151
Conversation
96d27c8
to
3c82aeb
Compare
@@ -22,6 +22,8 @@ There is no way to de-register an event handler. However, since the Lua | |||
state is built from scratch when the configuration is reloaded, simply | |||
reloading the configuration will clear any existing event handlers. | |||
|
|||
See [wezterm.action_callback](./action_callback.md) for a helper to define a custom action callback. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about adjusitng the custom events example below to use the new helper?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure, I think it's important to have an example using wezterm.on
and wezterm.action{EmitEvent=...}
explicitely, in case one wants to do something specific that would not be supported by wezterm.action_callback
(like using the event id in another custom action, to emit it manually with wezterm.emit(...)
).
I can write another simpler example below it though to show its usage in this doc file?
(the same as in the docs for wezterm.action_callback
? or the same example as below, but without the comments ?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about both in the same example? If the line starting wezterm.on("trigger-vim-with-scrollback", function(window, pane)
becomes a helper function definition, rather than a closure: function trigger_vim_with_scrollback(window, pane)
,
then we could show the new action_callback
example first:
return {
keys = {
{key="E", mods="CTRL",
action=wezterm.action_callback(function(win, pane)
trigger_vim_with_scrollback(win, pane)
end)
}
}
then show the older/discrete way as an alternative:
wezterm.on("trigger-vim-with-scrollback", trigger_vim_with_scrollback)
return {
keys = {
{key="E", mods="CTRL",
action=wezterm.action{EmitEvent="trigger-vim-with-scrollback"}},
}
}
Looks good, thanks! What do you think about expanding the examples to show it off? |
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
Following up on https://matrix.to/#/!PirwUBcuIlTXwNveYz:matrix.org/$ets1eEk2ixZ3MgxHLrrpOoo2Rg3VI6Cg4z82IYxsOqA?via=matrix.org
I couldn't find a way to get the filename/linenumber of the call to use it for the event name without trying to use unsafe code.
It's actually not that bad, because as error in the callback will show a traceback with correct filename/linenumber.
🙃