-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Add a spec draft for Keybindings Arguments #1349
Conversation
Specs #1142. Just read the spec :)
binding automatically recieves the number pressed as an arg? I couldn't find | ||
any prior art of this, so it doesn't seem worth it to try and invent | ||
currently. This might be something that we want to loop back on, but for the | ||
time being, it remains out of scope of this PR. |
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.
Link future idea to open issue?
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.
Good spec draft. This sets a great example. I didn't have any major issues.
Co-Authored-By: Carlos Zamora <[email protected]>
Might not need to be on the spec but don't forget about Dustin's Design Notes here regarding |
``` | ||
|
||
Note that instead of having 9 different `newTabProfile<N>` actions, we have a | ||
singular `newTabProfile` action, and that action requires a `profileIndex` in |
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.
is this informative or normative? That is: does the spec specify that newTabProfile
MUST have an index or that it MAY have an index? What about a GUID?
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.
Huh. It makes sense that it could alternatively have a GUID. But then how would we handle if both existed in the args
? I guess we can't really have an optional member, now can we?
* Split up ActionArgs and ActionEventArgs * Clarify _not_ handling an action * Add some notes on parsing args * Add some future considerations on extensions
…ntArgs` implementations, as they're redundant.
This commit also transitions our keybinding events and event handlers to a TypedEventHandler model with an "event args" class, as specified in the keybinding arguments specification (#1349). In short, every event can be marked Handled independently, and a Handled event will stop bubbling out to the terminal. An unhandled event will be passed off to the terminal as a standard keypress. This unifies our keybinding event model and provides a convenient place for binding arguments to live. Fixes #2285. Related to #1349, #1142.
Summary of the Pull Request
The goal of this change is to both simplify the keybindings, and also enable far
more flexibility when editing a user's keybindings.
Currently, we have many actions that are very similar in implementation - for
example,
newTabProfile0
,newTabProfile1
,newTabProfile2
, etc. All theseactions are fundamentally the same function. However, we've needed to define 9
different actions to enable the user to provide different values to the
newTab
function.
With this change, we'll be able to remove these essentially duplicated events,
and allow the user to specify arbitrary arguments to these functions.
References
Might play into #968, since there's some discussion of to munge or not to munge with the default keybinding for copy. This would make it easy to add both.
PR Checklist
Detailed Description of the Pull Request / Additional comments
Just read the spec :)
Validation Steps Performed
It's a spec.