FindWidget/TerminalFindWidget: Provide random access to search matches via an inline "Nth Match" input field. #309109
Open
boborrob wants to merge 18 commits intomicrosoft:mainfrom
Conversation
- Proof-of-concept UI changes - Add an editable numerical input field to the findWidget that allows the user to jump to matches a la random access (jump functionality pending)
- Proof-of-concept API/functionality changes - More compliance and alignment with existing data model and class hiearchy - Misc bug fixes pending - Cleanup pending
- Better file and class names - Better alignment with findController and findModel APIs - Register a new `MoveToEditableNthMatch ` EditorAction - Add More key event handlers (not finished) - Enforce width of the input box - Don't recreate the input on every update. - Consider adding scroll event listener for mouse-driven step functionality - Cleanup still pending
- Restore 'No Results' error message when the input search string yields 0 matches. - Fallback to default text input element behavior. - Add up/down arrow key support for step behavior native to numerical input elements. - Remove unnecessary comments and scar tissue.
…get . - UI/API proof-of-concept. - Build, link and troubleshoot a local build of @xterm node_module, modified to support nth match. - Before fixing focus-retention issue of NthMatchInput in terminal simpleFindWidget
- Fix focus-retention issue - Use the incumbent dom.FocusTracker to handle focus and blur events
- Fix the focus-retention issue. - Use the incumbent dom.FocusTracker to handle focus and blur events.
- Combine editor and terminal changes
…to access match instances arbitrarily.
… to access matches arbitrarily.
- On input/change, update the width of `nthMatchInput` to fit the length of its value - Test the editor and terminal finders at their pre-defined `MATCHES_LIMIT` of `19999` matches.
Author
@microsoft-github-policy-service agree |
- `findWidget`: Refer to `nthMatchInput`\'s `domNode` like the surrounding `focusTracker`s do with their respective controls. - `terminalFindWidget`: Investigate coupling of `themeService.onDidthemeColorChange` events to the `find(previous: boolean)` call . The normal `findWidget` has no such coupling. Is this intentional?
Contributor
📬 CODENOTIFYThe following users are being notified based on files changed in this PR: @kycutlerMatched files:
@jrualesMatched files:
|
… normalize placeholder text
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Allow users to access search results arbitrarily using an inline input field in the
findWidgetandterminalFindWidgetcomponents.Motivation:
For large sets of search results, cycling through matches sequentially can be cumbersome and time-consuming, especially when the relative location of the desired match is already known with some certainty. An input allows the user to jump arbitrarily to the desired match or to at least get closer to it much faster.
The editor exhibits a similar behavior already, but the means for invoking it are buried in the
quickInputservice. With this change, the functionality is presented upfront with no real cost to the existing UX. The information presented to the user at the outset is the same. Except now, there's an an inline "knob" the user can turn for more granular control over the search experience.The terminal editor benefits from this change too, and since it's an upstream dependency (xterm.js), the change is implemented there as well. See this PR for details.
Example Usages:
Future Enhancements:
matchesCountwidget is clicked.