fix: incorrect line skipping in renderer flush

[semihbkgr]

fixes #1232

To fix the bug described in the issue, we can simply store the currently rendered lines and use them for comparison in the upcoming flush operation.

[semihbkgr]

It seems that the bug was introduced in #1132 after this change:
https://github.com/charmbracelet/bubbletea/pull/1132/files#diff-eec1160b5c25625c859865f3ea86e45e76521a2dd877c78a508183b968646f7dL194

[meowgorithm]

Totally, this is a regression. Appreciate all the work and insight on this one, @semihbkgr; we’re checking this out now.

[aymanbagabas]

I tested it with the provided example and everything seems to work as expected.

@semihbkgr Could you please add comments in the code explaining why you're doing this? I know you explained this in the issue, but it would be more beneficial to have some explanation in the code 🙂

[LeperGnome]

I could reproduce the bug, yea

[meowgorithm]

@LeperGnome and does this patch fix it for you?

[LeperGnome]

@meowgorithm I found out that this bug was present in the original renderer before 1.2.0, but in a slightly different form... I'm tinkering around, still can't really wrap my head around it. I managed to fix it myself by:

	r.lastRender = strings.Join(newLines, "\n") // instead of r.buf.String()

But I didn't test current patch yet.

EDIT:
current patch fixed the example from the related issue, but I didn't test anything beyond that.

[LeperGnome]

Yea, as @semihbkgr pointed out in #1232 it seems like the issue lies in the fact, that lastRender contains all the lines (even not rendered) from the previous frame, and newLines are being trimmed to fit the window height. So at the end, we don't match lines correctly to see if they're the same. ouch

[LeperGnome]

Oh, wait.. @aymanbagabas did you reproduce the bug or not? I might've misunderstood your comment

[aymanbagabas]

@LeperGnome Yes, I was able to reproduce the bug. This patch fixes the issue

[semihbkgr]

We can possibly remove the linesRendered field and use len(lastRenderedLines) instead. What do you think?

[aymanbagabas]

It will break tea.Println. We reset the lastRenderedLines when we call repaint, which is the case when using tea.Println. We need to keep track of the number of lines last rendered for tea.Println to work.

[LeperGnome]

As a side note - maybe it's a good thing to introduce tests for such corner-cases? I'll definitely help when working on new renderer.