GNOME Bugzilla – Bug 792885
Find -> Clear Highlight doesn't work
Last modified: 2021-06-10 21:21:41 UTC
.
There are other small issues as well. - Clicking in the terminal area removes the highlight of the current match (even if that click was made solely to give back focus to the terminal). Next/Prev shortcuts still work, but they start over. I'm not sure, I guess I'd expect mouse clicks to be irrelevant – although conflicting mouse highlight are sure a problem, but maybe we could defer removing the search highlight until selecting is started. And even then I guess searching should continue from the last location. - Clear Highlight doesn't visually unhighlight the match, but otherwise cancels the search operation. Subsequent Next/Prev operations do nothing. Up/Down arrows of the existing Find dialog don't work either, at least not until the search word is left unchanged. The wording "Clear Highlight" suggests to me it should only affect the visuals; if canceling is desired then IMHO maybe the wording could go like "Reset Search" or similar.
Created attachment 369327 [details] [review] Fix Fix (for $subject only). vte_terminal_search_set_regex() cannot unhighlight automatically, because this one keeps getting called as you type the new regex, so it's expected that the visuals stay the same. (Semantically different behavior based on the NULL-ness of the new regex would be damn ugly.) So, given the current APIs, the caller explicitly has to make sure to unhighlight. (Another possible approach is for the caller g-t to perform a vte_terminal_search_find_next() using the freshly set NULL regex, plus a corresponding change in VTE to unhighlight before bailing in this case.)
(In reply to Egmont Koblinger from comment #1) > There are other small issues as well. > > - Clicking in the terminal area removes the highlight of the current match > (even if that click was made solely to give back focus to the terminal). > Next/Prev shortcuts still work, but they start over. I'm not sure, I guess > I'd expect mouse clicks to be irrelevant – although conflicting mouse > highlight are sure a problem, but maybe we could defer removing the search > highlight until selecting is started. And even then I guess searching should > continue from the last location. I guess that's because vte abuses the selection to store the point of the current match highlight.
(In reply to Christian Persch from comment #3) > I guess that's because vte abuses the selection to store the point of the > current match highlight. Yeah I kinda realized this after making the comment :)
Submitted. Not sure if we should keep this bug open for comment 1 – or perhaps they're just not worth the required refactoring.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7817.