Fix alternate-screen scrolling

[loops]

Hi Wez,

Did the test case you requested, but it didn't demonstrate the problem. So
after staring at it a bit more, found this one-liner. Hope it's okay.

[wez]

Seems like this is reverting #6099 which only just got merged.
@tbung what do you think about this and #6166 ?

[loops]

Yeah, i'm able to reproduce something like the bug in #6099 after applying this PR.

So, i'm not sure what the correct answer is to fix that problem, while not breaking alt-mode mux
scrolling. This PR made sense to me, since it seems logical that having no scrollback, should be
treated the same as having a deleted scrollback. But will leave it to all of you who actually know
and understand the codebase.

[tbung]

I'm busy until next week, then I'll take a look at what the difference between less and vim is here and devise another test case so we can come up with a solution to both issues.

[loops]

Hi tbung,

Looking for a test case, I found that the problem from #6099 isn't limited to
alternate screen mode, and reappears if you disable the alternate screen
capability. With Vim it's:

  vim -c 'set t_ti= t_te='

But for Neovim, you have to compile a custom terminal entry that removes smcup:

 tic - <<< 'noalt|fake term, rmcup@, smcup@, use=xterm-256color,'
 TERM=noalt  nvim

In either case, the split window problem, where the status bar floats up
the screen, shows up again.

The problem is that whenever an extra line is inserted in the upper scroll
region, it invalidates the StableRowIndex for all the lines below the scroll
region, but they aren't being marked as dirty.

[loops]

Hey @tbung,

I've had a couple kicks at the can already, but couldn't help trying again. Pushed an update that resolves the issues I was seeing. Let me know what you think. Hopefully it saves you a bit of time.

[tbung]

Works beautifully, thanks for figuring it out! Also, really nice that you added tests for both bugs now. This should now finally mean that #4607 is solved.

[loops]

Hi @tbung

That's great. I did just make a small push, to move the invalidation logic to the end of the function, which makes more logical sense, and fix a small comment in the tests. But it's otherwise unchanged.

We'll just see what Wez says now, and if any other cleanups or anything else is needed.

[kaddkaka]

Awesome that this is getting fixed 👍

Is the check "owner approval" referring to @loops in this case?