Comment 15 for bug 271487
Revision history for this message
| Egmont Koblinger (egmont-gmail) wrote | #15 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
2eb648a
demo site
(Get the code!)
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:/
https:/
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.