Replies: 1 comment
-
I have a vague suspicion that this behavior may be partially intended. I can imagine that auto-highlighting single-character search terms might be a performance issue. If that's the case, I would still give it further thought:
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Nature of issue?
Details about the bug:
Steps to reproduce
For both scenarios, have a sketch open with some content in it. Ideally the sketch has just been opened, so the options in the Find dialog have their default state: not a regex, not case sensitive, not "only whole words".
Scenario 1:
Result: All occurrences of the selected text are highlighted. Great.
Actual result: Nothing is highlighted.
Expected result: All occurrences of the single letter are highlighted in the sketch.
Result: Now, but only now, all occurrences are highlighed, and Find cycles through them.
Scenario 2:
Actual result: Nothing happens.
Expected result: All occurrences of the single-character search term are highlighted.
Result: Now, but only now, all occurrences are highlighed, and Find cycles through them.
Related: when I have a longer string in the input field of Find and I delete the last character, the occurrences in the editor are updated. When I have a two-character string and I delete the second character, the occurrences are neither updated, nor are they removed. This is confusing behavior because the highlights are now inconsistent with the state of the Find dialog.
Attaching screen grabs.
no-autofind-scenario-1.mp4
no-autofind-scenario-2.mp4
Beta Was this translation helpful? Give feedback.
All reactions