GNOME Bugzilla – Bug 78963
Ability to find/search text in buffer
Last modified: 2010-05-04 01:52:26 UTC
Basically, I'd love to be able to search for a string in the scroll buffer. Any strings found strings should ideally be highlighted somehow and perhaps the buffer should scroll back to the location of the last string. Finding again with the same text might scroll back to the one before that. Was thinking to use a popup with a textbox, a case sensitive checkbox and a find button. Why? Because I use long buffers and find myself spending a lot of time looking back through my buffer to look for something specific, like an error message or whatever.
Sounds like it might be a reasonable feature.
*** Bug 92471 has been marked as a duplicate of this bug. ***
I think this could be a really useful feature. It's one that I've wished for many times. The alternative is to pipe command output into less, then search through that. But: * I often don't realise I want to search through command output until *after* the command has started running * I can never remember the tricky 2>&1 bash syntax for redirecting both stdout and stderr to the same place Ideally the find in termianl text feature would be as quick and easy as Find As You Type is in firefox. I.e. it would be much better to have a key (e.g. Ctrl-Shift-/) activate incremental reverse search, then Esc would return the user to their regularly scheduled programming prompt. Thanks for gnome-terminal, it's pretty cool. Cheers, Matthew.
Using less is not an alternative when searching data of interactive sessions. I use ion2 window manager together with gnome-terminal, so I would appreciate, if you can avoid a popup window which is in the way and have rather a bottom input line for entering search term, just like current firefox does it.
*** Bug 171381 has been marked as a duplicate of this bug. ***
*** Bug 305421 has been marked as a duplicate of this bug. ***
*** Bug 336116 has been marked as a duplicate of this bug. ***
We were talking about this on IRC the other day. What we want is an incremental backwards search with a search widget that will overlay the terminal on the bottom left or right corner. It will highlight all search results in the current screen, like evince does.
I was about to submit a bug requesting this feature too, but searched first and found that it had been submitted several times already!
*** Bug 433006 has been marked as a duplicate of this bug. ***
There seem to be quite a few requests / duplicates for this already. Is there a way how can we push things (except coding it myself:)? The original bug is from 2002 and that's quite some time already. No kidding, this is a useful feature.
(In reply to comment #11) > Is there a way how can we push things (except coding it myself:)? Not that I can think of.
Search feature would be very useful for me too. Can I vote somehow for this enhancement?
Workaround, though somewhat drastic, could be to use KDE Konsole, which has a search feature. As a popup dialog, though ...
+1, I need this almost daily.. As the ability to highlight set of matches.
I've started working on a patch for this, I should have something in a few days. It doesn't seem all that difficult to do.
(In reply to comment #16) > I've started working on a patch for this, I should have something in a few > days. It doesn't seem all that difficult to do. > Great!
*** Bug 525366 has been marked as a duplicate of this bug. ***
*** Bug 533141 has been marked as a duplicate of this bug. ***
*** Bug 569618 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > I've started working on a patch for this, I should have something in a few > days. It doesn't seem all that difficult to do. > guess those few days are still a few days away. :) it's really ridiculous, that this must-have (see all the duplicates. qed.) is not implemented.
Please refrain from adding useless comments. It will not make bugs be fixed any faster.
I was looking at this on the weekend, and I have regexp matching in the search buffer working; just need to get the highlighting done. If anyone else wants to look at this feel free to contact me for what I've got so far, otherwise I'll keep looking at it when I have time :-)
Thanks Grahame, this is great news. Please keep working on it, I would owe you a beer!
Grahame, why don't you upload the patch you have got so far?!
Workaround that I currently use: select the whole scrollback buffer (tripple-click near the top, then hold down shift and tripple-click near the bottom), open a new terminal, type xsel|grep yoursearchstring. You need to have xsel installed, obviously. And you don't get to see context, but then again you could pipe xsel|less and do whatever you want.
(In reply to comment #26) > Workaround that I currently use: select the whole scrollback buffer > (tripple-click near the top, then hold down shift and tripple-click near the > bottom), open a new terminal, type xsel|grep yoursearchstring. > > You need to have xsel installed, obviously. And you don't get to see context, > but then again you could pipe xsel|less and do whatever you want. > Yeah! It could be a smart workaround if you had the "Select All" ability. But currently, in gnome-terminal, you do not.
Great! Marius Gedminas, work fine. Anyway, the search funcionality is necessary. Best regards.
Newish gnome-terminal has Select All in the Edit menu.
*** Bug 578328 has been marked as a duplicate of this bug. ***
*** Bug 582828 has been marked as a duplicate of this bug. ***
(In reply to comment #23) > I was looking at this on the weekend, and I have regexp matching in the search > buffer working; just need to get the highlighting done. did you implement this so far in vte or gnome-terminal, because my bugreport just got duplicated to this one and i explicit filed it under vte. this functionality should definitely go there :-) the highlighting and search api i mean with that.
ChPe, what's your current take on where this should be implemented? Fully in vte? Mixx'n'match?
API in vte and UI in g-t as usual, IMHO.
So, g-t draws the search box?
Created attachment 135121 [details] [review] Add a Find Dialog to GT Hi guys, Here's a patch to GT to add a Find Dialog. To keep things simple, I haven't made any changes to VTE and keep my GT changes to a minimum. Without changing VTE, the Find Dialog can't yet highlight the match. All it does is scroll the match to the top of the screen. The find dialog will search for strings in the buffer, starting at the current position and wrapping around. It has options to match the case; only search for whole words; search for regexes. I've tested it with ASCII and some Chinese pictograms. As for speed, it takes ~1 sec to search 100,000 lines. It stores its config in GConf under /apps/gnome-terminal/find I've attached: a patch against git://git.gnome.org/gnome-terminal a screenshot Diffstat: po/POTFILES.in | 2 + po/POTFILES.skip | 1 + src/Makefile.am | 3 + src/gnome-terminal.schemas.in | 77 +++++ src/terminal-find.c | 755 +++++++++++++++++++++++++++++++++++++++++ src/terminal-find.glade | 203 +++++++++++ src/terminal-find.h | 43 +++ src/terminal-window.c | 13 + 8 files changed, 1097 insertions(+), 0 deletions(-) Comments please... Cheers, FlatCap
Created attachment 135122 [details] Screenshot of Find Dialog Everyone likes a screenshot.
Thanks! I had more of a search bar in mind, like evince has. ChPe, if you handle the gnome-terminal part, I'll add the vte API!
Ordinarily I'd say popup dialogs are passé, and search bars all the rage in modern desktop apps. However there are unique considerations here: you can't easily change the size of the terminal area without causing undesireable side effects (SIGWICH signals to applications, sometimes lost bits of scrollback history). Changing the window size is not always possible either (consider a maximized terminal).
The bar can be an overlay; doesn't have to resize window or widget. It can even be translucent. Or not even a bar, just a box. Like the treeview search thing. We know that incremental search is much more useful than non-incremental. Specially so in a terminal. Search dialogs are boring. :)
I agree, a find bar would have to be overlaid so as not to resize the terminal. Would be nice to have such a find bar, but as a first step I'd accept a dialogue. The dialogue in attachment 135122 [details] has a few HIG probs but that's minor. Notes on the patch in attachment 135121 [details] [review]: How would match_whole work together with regexes? /apps/gnome-terminal/find/history_list: /apps/gnome-terminal/find/history_count: I don't think find history should be stored at all, and certainly not in gconf. +++ b/src/terminal-find.h Missing G_BEGIN/END_DECLS +} FindParams; Why is this public? +void terminal_find_display (GtkWindow *parent); Weird API. I'd expect this to be a find dialogue object (inheriting from GObject probably and just containing the real widget in priv data), with only public API like this: TerminalFindDialog *terminal_find_dialog_new (TerminalScreen *screen); void terminal_find_dialog_show (TerminalFindDialog *dialog); Esp. your design seems to be just one find dialogue globally; but it should be per TerminalWindow (and be modal to it). +++ b/src/terminal-find.c This part not really worth commenting on before we've the necessary API in vte.
ChPe, Any chance getting this in?
Behdad: I want this feature myself too! However, the vte API (comment 38 :-) is still missing, and there's no new g-t patch using it, or addressing my remarks in comment 41.
*** Bug 607583 has been marked as a duplicate of this bug. ***
I'm working on this, starting from the current patch and cleaning up my way through it. Pushing it in the 'search' branch.
I merged this onto master now. The g-t part is complete. "Clear Highlight" is currently disabled though since vte doesn't highlight yet. And no interactive search for now, although it would be really easy to add it. The vte API is kinda right, but the implementation leaves a lot to be desired... But kinda works...