-
Notifications
You must be signed in to change notification settings - Fork 217
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
support modifying default keybindings prototype #356
Conversation
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.
Looks like a great direction. I have some suggestions you play around with that might simplify the code
config/parser.go
Outdated
helpDesc = previous.Help().Desc | ||
} | ||
|
||
if len(kb.Keys) > 0 { |
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.
Do you expect people to want alts? Is this a personal need of yours? I don't expect many users will actually define multiple keys for the same action.
If there's not a big use case, maybe it's better to omit to reduce the config bloat
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.
Yea I wasn't entirely sure, I can't see myself particularly using it. So that is fair.
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.
Removed in latest commit
ui/keys/keys.go
Outdated
|
||
func rebindUniversal(universal []config.Keybinding) error { | ||
for _, kb := range universal { | ||
log.Debug("Rebinding key", "builtin", kb.Builtin, "key", kb.Key) |
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.
nice :)
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.
Will be adding to prs and issue keys as well.
ui/keys/keys.go
Outdated
Keys.Up = kb.NewBinding(&Keys.Up) | ||
case "down": | ||
Keys.Down = kb.NewBinding(&Keys.Down) | ||
case "firstline": // should this be first-line or firstLine? |
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 think firstLine
would be more readable
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.
Using camel case for keys in next commit.
* Remove keys and just use key * Handle issue and pr keys * Handle all keys in universal
Any chance for a new of this by @dlvhdr ? Would love to be able to rebind the comment navigation. |
@miniscruff would you like to resolve the merge conflict and merge? |
If I remember correctly I was running into issues still around keybinds used in both views not behaving properly. I can put in some time in the next few days to try and finish it. |
ui/ui.go
Outdated
// I do not think this state machine works quite well enough with custom keybinds | ||
// as it kinda breaks down if you use two different keys across the views. | ||
// Is it worth refactoring this to first check the "view" before the key? |
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.
@dlvhdr just a question here about the keybind checks. I noticed we are checking for both PR and issue keys at once which sort of breaks if you bind to two separate keys. Wanted to clarify before I made any major changes.
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.
Yeah you're right, we would have to first check the current view
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.
Do you want me to make that change now or leave it for you?
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.
Making the change would be very appreciated 🔥
ui/ui.go
Outdated
// I do not think this state machine works quite well enough with custom keybinds | ||
// as it kinda breaks down if you use two different keys across the views. | ||
// Is it worth refactoring this to first check the "view" before the key? |
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.
Yeah you're right, we would have to first check the current view
Today is the day I finish, and now that I said it, it must come true. |
At risk of causing any late-stage headaches here, I have to question if it might not be best to specify the view/context the other way around in the config format; have a keybinding specify which context or contexts it should apply in. I don't know the full scope you (currently) want the project to cover, but there are theoretically quite a lot of different screens and contexts that could be added in future, which could result in some technical debt with this design. It could easily be desirable to have bindings that apply to multiple views, or to contexts which aren't strictly views but, well, broad contexts (dialogue boxes, text entry fields, lists/tables... even the current 'universal' tbh, though that option wouldn't be without it's own potential technical debt), and having the binding list where it applies is IMO a lot more robust, flexible, and future-proof (added bonus that you could disable a binding by commenting out it's context in the config file). |
handle the pr and issue keys in different cases * remove universal switch view for per view binds v4
Thanks for contributing this @miniscruff, it's very useful! |
Fixes #214
Open questions:
Not sure if this mega switch case is really the way to go, I thought of creating an enum but either way we have a separate string to keybind map.
Not sure the yaml value for multiple words should be "switchview", "switchView" or some other method.
I had to change the Keys to a pointer so I can actually update them after the initial load. I am not sure if this is ok or if there is some other refactoring/change that would make more sense. For example, I tried putting a KeyMap on the shared ctx that has the config on it. And then just loading it on init, but it pushed more changes that I thought would be appropriate.
I am not sure how to handle the multiple key options for alts. I created a
Keys []string
that can be used that mimicsKey string
but with multiple. So it should be backwards compatible but not sure if there was another method you were expecting.There is an error log on an invalid config, which will need to expand to an invalid config or after that, an invalid keybinding, such as a bad builtin. I am not sure I handled this properly, or if there is a better way, let me know.
Summary
Allow modifying the builtin command keybindings.
How did you test this change?
I have a test config with the new universal option. Currently this is all I am testing.
Images/Videos
https://www.twitch.tv/videos/2176382326