@ngraham as this needs input from the VDG
I personally love the idea, I would change the half of the page dimm effect by a thin line on the side (like kdevelop shows for edited lines)

I tried several things, this full-size dimming was the option I liked best, but I am opened to other ideas of course.
VDG input will be usefull indeed.

When I test this patch on dmesg output, I only see the top or bottom two lines becoming highlighted in this way. Is this intentional? Or am I doing something wrong? Or is it buggy with this output?

Oh hmm, that was only with my wheel mouse. With touchpad scrolling I see more lines highlighted.

To be honest I don't feel like this is very useful. But maybe I'm not using it right? Or maybe we should step back consider alternative ways to solve the problem as stated in the description.

Maybe like this?

• something sometimes outputs always the same line (debug message) to a terminal. Does it spams the line in a loop right now, or I'm looking at previous lines? (for this the feature would need to work for new lines too)
• Repeated scrolling is distinguishable

With indicator on a side instead of full lines animation should be lightweight.

For a search, or bigger jumps in general, semi-smooth scroll (like 0→50 scroll above, but faster) could be nice (or annoying, I'm not sure yet). But thats something for separate and independent feature.

I can see how this could be useful. If we use the current visual effect, we'll have issues w/ different colors (ie the fade not being easily seen). Perhaps the side visual might be better? At one time, there's a wish to have the scroll bar similar to Kate in that it shows a representation of what's in the window in the scrollbar.

Hi everyone,
I would like to carry on working on this patch, I keep compiling my own version of konsole just for it. This patch is very valuable in situations where I have to go through logs with _very_ similar lines (which happens quite too often for my job) and I need to keep precise track of where I am while navigating. As Nate pointed it, this is not so useful when scrolling one line at a time, but when using the half-page jump with Ctrl-PageUp/PageDown, it becomes essential to have a visual hint of what lines have come into view.

In D21055#465869, @mglb wrote:

Fading out solves additional use cases:

• something sometimes outputs always the same line (debug message) to a terminal. Does it spams the line in a loop right now, or I'm looking at previous lines? (for this the feature would need to work for new lines too)
• Repeated scrolling is distinguishable

This looks really nice and would indeed make this patch useful in the case of scrolling. But fading based on a timer would kill the main feature I see in this: having a visual reference to be able to see what has moved. Maybe we have to find something in between the original proposal and this. What do you think ?

Other question: should I keep this on Phabricator ?

This looks really nice and would indeed make this patch useful in the case of scrolling. But fading based on a timer would kill the main feature I see in this: having a visual reference to be able to see what has moved. Maybe we have to find something in between the original proposal and this. What do you think ?

What about: quickly fade down to e.g. 50%, keep this for N seconds (configurable, up to infinity) or until next scroll happen, then fade to 0%? This should solve your problem (new lines are marked as long as you want) and indicate that new scroll happened.

You can use phabricator for now if that works for you - setting up a merge request https://invent.kde.org/kde/konsole/merge_requests would also work. Until phabricator is removed, it is up to you which patch is easier to maintain.