GNOME Bugzilla – Bug 627886
Search improvements
Last modified: 2021-06-10 14:25:53 UTC
Just a list of things that can be done much better in the vte buffer search stuff: - Right now we search text one line at a time. With regexp search, it should be able to do multi-line searches. Doing that right is *very* hard currently. To do it easily, we'd need pcre/gregex support for 1) backward search, 2) an iconv-like "give me more text" api. - Multiple results per line are not found currently. - Highlight-all-matches doesn't exist. - We should directly search on the UTF-8 text that we already have in the history buffer. Instead, we get the rowdata and convert to UTF-8 again. Suboptimal. - Currently we use selection as our last-search-position iterator. Works great most of the time and is kinda what gedit does too. But currently if you "Find Next" while at the last result, we unhighlight the last result. Most search implementations don't. (brought up in bug 627258) Perhaps much much more.
*** Bug 633634 has been marked as a duplicate of this bug. ***
*** Bug 633627 has been marked as a duplicate of this bug. ***
*** Bug 633630 has been marked as a duplicate of this bug. ***
Another strange bug, The highlighted text (searching result) will be cleared if the text in primary clipboard had been changed, then calling vte_terminal_search_find_next() will search from beginning.
(In reply to comment #4) > Another strange bug, The highlighted text (searching result) will be cleared if > the text in primary clipboard had been changed, then calling > vte_terminal_search_find_next() will search from beginning. Yep. That's because as I said: "Currently we use selection as our last-search-position iterator."
Another strange behavior: We can use "vte_terminal_search_set_gregex (vte, NULL);" to unsets the search regex, But it won't un-highlight the selected text.
(In reply to comment #6) > Another strange behavior: > We can use "vte_terminal_search_set_gregex (vte, NULL);" to unsets the search > regex, The idea is that when in the future we implement "highlight all results", then setting gregex to NULL will dehighlight those. > But it won't un-highlight the selected text. This is expected IMO since it's really the selection we are changing.
If I weren’t such a noob, I would try to fix 2, 3 and 5 because search would be even more useful with these. It’s a little clunky now, but I still use it all the time now.
Behdad, will you find the time to complete this thing eventually? I'm using search in gnome-terminal almost daily and wish the quirks would get ironed out.
I don't currently have any plans to look into it. The code is very short and simple though, you should feel free to play with it. What quirks are most annoying? Maybe I can look into fixing one or two quickly.
I feel it would not be efficient use of time if I tried. But I would otherwise; nolens volens. Highlighting all matches and finding more than the first match in the line are the most pressing issues.
Yeah, we abuse the selection to track last match. Totally bogus. Highlighting all matches would be considerably more work...
(In reply to Behdad Esfahbod from comment #0) > - Right now we search text one line at a time. With regexp search, it > should be able to do multi-line searches. Doing that right is *very* hard > currently. To do it easily, we'd need pcre/gregex support for 1) backward > search, 2) an iconv-like "give me more text" api. PCRE2 can do this incremental matching (forward only though, I think?), see man:pcre2partial(3) (or man:pcrepartial(3) for old PCRE, which is the same info but for the old API). I'm about to add PCRE2 support to vte directly instead of via GRegex, so we don't need to wait for any more GRegex improvements.
Sounds good to me!
Re backwards matching in pcre, perhaps we should at least communicate that to them.
Filed the backwards-matching in pcre here: https://bugs.exim.org/show_bug.cgi?id=1694
Hi, I just wanted to "vote" for the highlights all results feature, as it will make the search function much more useful. Thanks!
I also would like to "vote" for the feature consisting in highlighting all the occurrences. When you're reading a dense text with a command that doesn't support the search function by itself (i.e. when you use "tail -f"), it's a very useful feature.
Another vote for "highlight all" - this kind of instant grep through screen contents is very useful, and so far I've only found two terminal emulators implementing this correctly - iterm3 (for osx) and konsole.
*** Bug 780565 has been marked as a duplicate of this bug. ***
-- 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/vte/-/issues/1830.