fix(settings): prevent j/k navigation keys from intercepting edit buffer input#21865
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a keybinding conflict within the settings dialog. Specifically, it prevents the 'j' and 'k' keys from being incorrectly interpreted as navigation commands when a user is actively typing in an input field. The changes ensure that these keys are correctly inserted into the edit buffer, while preserving arrow key navigation functionality. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request resolves a keybinding conflict in the settings dialog where 'j' and 'k' keys were being intercepted as navigation commands instead of being treated as text input. The changes correctly add a !key.insertable check to the navigation handlers for both edit mode and when the search box is enabled. This ensures that arrow keys continue to function for navigation, while 'j' and 'k' can be correctly typed into input fields. The implementation appears to effectively resolve the issue.
Note: Security Review did not run due to the size of the PR.
|
Thank you for this PR, I've verified it works locally on my end. Can you resolve merge conflicts and add tests for this? |
Yeah, I am working on conflicts. |
|
fyi you might be better off re applying the change on an up to date branch and force pushing b/c basesettings was refactored heavily |
868de0a to
dcf664e
Compare
Re-applied the changes to the updated branch and forced push the changes there. |
|
@student-ankitpandit I would recommend to minimize the scope of this fix only to the inline editing buffer, this means that users will still not be able to use j and k inside of search. notably this behavior has existed since even before #18963 Then your tests will pass and you will have resolved the issue regarding inline editing, another issue should be filed to discuss a path to resolve the search UX. |
psinha40898
left a comment
There was a problem hiding this comment.
IMO the cleanest solution here is to confine your change to just the inline edit buffer if possible.
After that, I think we should be using effectiveFocusSection or else your changes won't work when the UI conditionally hides the Scope menu and the user presses tab
deferring to the assigned reviewer @Adib234 from here
Good luck
018c0ff to
938477b
Compare
| // can be typed into the search box instead. Arrow keys always work. | ||
| if ( | ||
| keyMatchers[Command.DIALOG_NAVIGATION_UP](key) && | ||
| !(searchEnabled && key.insertable) |
There was a problem hiding this comment.
this will not pass cli ci unless you revert this change. the solution here is beyond the scope of your PR. fix edit buffer not search
d32942d to
98b5743
Compare
|
My bad, I forgot to add the GEMIN_API_KEY in the repo secret of my fork. |
|
All 26 test cases has been passed, but there is the issue with the branch. I try to update the branch many times but after a while again the pop-up appears again saying your branch is out of date. |
|
there's no issue. you don't need to update the branch if there are no merge conflicts detected. just add a regression test (confer with llm and use it as learning exp if u never did this before) after that the pr should be good to go |
Sure i will do and btw thanks for correcting me. |
|
Edit buffer works as execpted, but i'm bit concern about the search it's still can't accept k and j as insertable keywords in the search of the settings. User still can't search about a setting start with k and j. |
There was a problem hiding this comment.
Code Review
This pull request correctly addresses a keybinding conflict in the settings edit mode. The change prevents the 'j' and 'k' keys from being intercepted as navigation commands when editing a field, allowing them to be used as character inputs. The fix, which involves checking the key.insertable property, is targeted and effectively resolves the issue while maintaining existing navigation functionality with arrow keys. The implementation is sound and I have no further recommendations.
you need to add a regression test fixing search is beyond the scope of your pull request |
|
A regression test is a test in |
|
Thank you! lgtm Thank you for letting me help review it should be good to go now |
|
Everything looks goods to me. |
|
Thanks for your review @psinha40898 ! |
Summary
Fixes the keybinding conflict in the settings edit mode where pressing 'j' or 'k' while typing in a string input field (e.g. Plan Directory) would trigger vim-style navigation instead of inserting the character into the edit buffer.
Details
When a settings field has a string value type (e.g. Plan Directory), pressing 'j' or 'k' while in edit mode was being intercepted by the vim-style navigation handler before reaching the input buffer.
The fix adds
!key.insertablecheck to both DIALOG_NAVIGATION_UP and DIALOG_NAVIGATION_DOWN handlers in edit mode, so that:This mirrors the existing fix already in place for the search box, where the same
!key.insertablepattern was already being used.Related Issues
Fixes #21746
How to Validate
gemini/settings/projects/jekyllEdge Case (uppercase J and K)
/Projects/JekyllPre-Merge Checklist
NOTE: Tested on Ubuntu (Linux) via WSL on Windows.
Fix is platform-independent as it only modifies
keyboard event logic.