terminator need to highlight search string

Assigning to Tom for a comment on the feasibility of this.

I was looking at this, and I think the solution would be to use http://ruby-gnome2.sourceforge.jp/hiki.cgi?Vte%3A%3ATerminalAccessible

and http://www.pygtk.org/docs/pygtk/class-atktext.html

With http://www.pygtk.org/docs/pygtk/class-atktext.html#method-atktext--get-bounded-ranges we should be able to get the chunks of tet for this specific terminal, send we can highlight (setting the selection).

It seems that the vte.Terminal.ref_accessible method is the way to get the atk object with python. However, it returns a atk.NoOpObject which means that there are method collisions (atk.Selection.add_selection shadows atk.Text.add_selection, for example). And, in my limited tests, all of the methods are broken (get_text always returns None, get_character_at_offset always returns \0, get_bounded_ranges dies with the cryptic "error return without exception set"). So I'm not sure if the accessibility interface is incomplete in VTE, or the python bindings are botched, or I'm using it incorrectly--but something is screwy with it (the ruby bindings didn't work either--they threw Vte-CRITICALs when I tried to call any method on the atk object returned from ref_accessible--same thing when I manually instantiated a Vte::TerminalAccessible).

It is very difficult to use terminator without higlighting search string.
What about this bug?
Can anybody fix it?

+1 on this

Would really love to have this feature

I'm unable to use the find feature without this.

This is an essential feature. Really need to add this.

Really need this!

+1. This is an essential feature.

really it is needed !

+1 it is needed.

Highlighting is done by vte, it can't highlight more than 1 match at a time. I _think_ search is also handled by vte and at most 1 match per logical line is returned.

Adding this feature would require extending vte's capabilities. I'm open to that, let's hope vte's main developer is also willing to accept this. Plus we need someone to implement it, I can't promise I'll have time.

Hijacking the accessibility framework doesn't sound right to me at all.

@Egmont: The bug is asking for highlighting of a string, not necessarily all of them at once, because right now the search has no highlight, making it hard for the eye to find the text.

I did some digging through how the search works in GNOME Terminator, and realised that for some reason the implementation in Terminator does it's own searching through the buffer rather than simply using the vte gregex/next/previous stuff. It's quite a chunk of code and I'd like to/will fix it, but it's not a five minute job. Once we start using that built-in function, then we will get highlighting, and it will simplify that whole section of Python code.

Of course it would be nice to highlight all matches at once like "less". Having said that, can I make a sly request (ulterior motives ;-) that rather than just extending vte to highlight the search matches, a generic API way to adjust formatting of any part of the scrollback buffer text temporarily is created as part of it? ClusTerm (v.old Perl program that also used vte) used to have a highlight differences feature. It worked by copying the text out, and then overwriting text with new attributes, which is really ugly and buggy.

@all the +1, me too, etc comments : Please don't do that. At the very top there is a link for indicating that this affects you. If you can't contribute useful information, or code, there is no need to post a comment.

I had no clue Terminator had its own implementation for search; makes sense now.

As for the highlight API: Do you mean something that from Terminator you want to specify things like "row 8 columns 10-12 should be italic; columns 13-20 should change to yellow background..."? I guess this should always be a temporary override for the attributes; once revoked via the API, the cells would get back to their previous attributes. Are we on the same page so far?

It's an interesting question that we should probably think about.

There are some questions to figure out. Would it allow attr changes for the currently visible part only, and in that case would the app (e.g. Terminator) continuously recompute and let Vte know what to highlight, each time you drag the scrollbar? Or would it allow to specify attributes for the entire scrollback region? In the latter case, would you allow to define only a couple of them (so that all of them easily fit in memory) or as much as you wish (in which case they'd need to be stored on disk along with the scrollback - sounds pretty hopeless)? What would happen to the attributes when the onscreen contents change? If you make it an API, you need to provide reasonable answers for these questions (that is, a detailed specification to go for).

Something that sounds reasonable to me at this moment is to work on the visible bits only and somehow Vte should notify the app each time the contents in a line change so that the app can update what to paint. Or maybe the other way around: the app could register a hook which Vte calls back: "hey I'm about to paint this line, do you want to override some of the attributes?"

This sounds like a more generic approach to the current regex/dingu feature, whereas it wouldn't be the app telling Vte the rules via a quite limited API, but rather the app looking at the entire screen (or at least an entire logical line) and deciding on its own (using arbitrarily complex logic) what to do and only telling the final result to Vte.

An example where this could be useful is to implement grouping digits by 3 onscreen either via colors, or via ticks after every 3rd digit, as brainstormed in these sibling tickets:
https://bugzilla.gnome.org/show_bug.cgi?id=741728
https://gitlab.com/gnachman/iterm2/issues/1814

Maybe the mouse position could also be reported to the app, and the whole regex matching removed from vte and let the app implement it. Or implement whatever it wants. It would the app - seeing the contents of the entire logical line, plus knowing if the mouse is over one of its cells, knowing which modifier keys are pressed etc. - deciding which cells to underline, which to color differently, whether to change the mouse pointer shape; using either the same regex stuff that we have in vte right now, or any arbitrarily more complex logic as it wishes.

@Egmont: Wow, that's a lot of food for thought, very interesting ideas, and almost certainly the subtleties of the best methods within libvte would be beyond my limited understanding.

Yes, your second paragraph nailed it with respect to my naive view of what I'd like. However this is getting way beyond what this bug is actually about, so let's move this discussion elsewhere, to somewhere more appropriate. What do you think? A new bug here, a blueprint here, a bug against libvte in it's bugzilla? I think this might be the rare occasion where a blueprint is actually useful :-D

vte bug would be the best place. Feel free to submit the request with your own wording, or I'll do it in a couple of days. Note, however, that probably no work will happen on this for quite a few years - it might be a nice idea, but given our limited resources, I doubt any of us would jump right on it.

I'll make a piece of code to futz it like ClusTerm did that is so horrible it will guilt trip you into doing it sooner just to eradicate such atrocities ;-)

I was digging around this tonight, and it's a bad news, good news, situation.

Bad news: The vte search methods are not exposed in the pygtk bindings. Probably because the GLib regex class isn't exposed either, which they depend on.

Good news: Due to GTK3 using Introspection, it looks like they are both exposed there. So this cannot be fixed in trunk, but can be in GTK3 branch.

I'll assign this item to the Terminator 2.0 milestone.

Just an encouragement.

Hopefully we'll get this feature through!

+1 would like to see it also :D

Just an encouragement. +1

Thanks for the amazing work you've done so far. As a person who depends on Terminator for his Sanity at work, this feature would improve my quality of life immensely.

This is THE feature that is missing ! +1 :)

OK, So here's a provisional patch (#26). There's some bugs to it though, and I'm a bit too tired to figure them out right now.
1) First match does not get highlighted
2) First match does not disable the previous button
3) When clicking down through the matches, then back up to the first, the scrolling jumps to the bottom.
I think these are all related to the clunky method used to detect if there's a next/previous match.

The attachment "Partial fix" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Fix committed in rev 1773.

I abandoned the search ahead and back that was causing me grief. The positioning in the scrollback buffer was getting very messed up. The code h cleaner now, and the behaviour matches gnome-terminal. It would be nice if there was a way of finding out if there were matched before/after the current highlight without having to perform mickey mouse searches, but this is the hand the API has dealt. Deal with it ;-)

Encouragement note! This is the only reason I had to go back-and-forth between different terminal alternatives.

Can we please do the 2.1 Bale release?

+1 , this is super usefull!

bump.

Soooo given that this has had a fix committed for just under a year, when can we expect to see it in stable builds? It's the one thing that's keeping me on Tilix. Thanks!

Please release this feature soon..i love terminator and this feature will make it complete.

10 years :(

I volunteer to donate or do something for making this feature available on stable builds.

Loving terminator, recommend it to everyone and really want this search feature.

Hoping, one day we'll get this feature in stable builds.

Thanks.

+1

+1

+1

C'mon, it's been 11 years. +11

+1

I have created this issue with the new GitHub project: https://github.com/gnome-terminator/terminator/issues/4

+1

+1

Fixed on GitHub

Hey This is fixed but the devs doesn't have access to update the ubuntu repo!!

Please someone add this to the ununtu repo!!
https://github.com/gnome-terminator/terminator/issues/4