Lines that could be partially visible aren't rendered at all

[eteran]

NEdit5 only rendered lines that were entirely visible. This wasn't an issue because the window could only be resized in whole character increments.

So, we should either:

1. Find a way to make NG only reliable in whole character increments (doubtful that this can be done sanely).
2. Implement rendering of this partially visible line in a complete way, including a policy that if the cursor ends up on that partial line, that it is scrolled into full view.

See extended discussion in: #270 reported by @tksoh

[eteran]

@tksoh since you originally reported this, I have an update for you.

This is proving to be hard to get right. I can get it almost there, but it has quirks. The worst of which involves vertically resizing a window while the bottom line is partially visible. It definitely doesn't act "right".

So I'll keep poking at this one, but I'm not sure if it should be a 6.0 milestone.

[tksoh]

It looks like Qt Creator is able to handle it 'correctly', i.e. display the partial line, and automatically scroll up by one line when the cursor is moved to the partial line. Perhaps it's worth checking out how they manage it?

So I'll keep poking at this one, but I'm not sure if it should be a 6.0 milestone.

It's not ideal. But it's really your call.

[eteran]

@tksoh Yea, Qt creator does handle it fine. It's not a "Qt" thing though, NG renders things quite custom (as NEdit5 does). It all has to do with tracking the last line, if it's a partially visible line, and what to do when things like the cursor land on that line.

The current code is very carefully tracking all sorts of aspects of the "visible" buffer so it knows what to do in all of the edge cases. Tweaking it is proving to be a delicate process. It's definitely doable, just won't likely be simple

[tksoh]

@eteran I am aware it's not a Qt thing. Anyway...

Just want to point out, the moment NG is started, there's already an extra blank area right below the last displayed line, probably depends on the font settings. As we zoom in & out on the font size, the blank area also grow or shrink along. And at certain font size, the blank area can become quite prominent. In any case, it may or may not become a problem to the users, depending on their tolerance. Some probably wouldn't even notice, but once we are aware of it, it can be a little distracting.

I have no issue if you leave this off 6.0.

[eteran]

@tksoh Ah gotcha, I misunderstood what you were getting at when you mentioned Qt creator, my bad.

So yea, it's definitely gonna be dependant on font sizes for sure. It should be at most be the font height minus one pixel. For a larger font, that can indeed be pretty pronounced.

I can say that regarding Qt creator, they are in some ways less custom than NG and in other ways more custom. Last I looked, they were basically taking the stock QPlainTextEdit and adding all of their own custom stuff to it. So they inherit all of the basic QPlainTextEdit text rendering functionalities and then layer on all of their custom stuff.

Truth be told, my first attempt at NG basically tried to do this, and while it "worked", I couldn't get things to act quite the same as NEdit5, I didn't want my port to look like NEdit, but behave wildly different, so in the end, I just decided to port NEdit5's rendering algorithm as directly as was practical. (This does mean that future Unicode work may be a nightmare to implement right to left language support... but one thing at a time!).

[tksoh]

@eteran no problem. BTW, I'm sure no one would dare say porting nedit to another toolkit is a not a tremendous effort, especially given how well NG works already -- it's very close to a miracle. You are much more qualified than anyone to say what can or cannot be done in Qt, as least as far as nedit is concerned ;-)

I'm hopeful you will find the solution to the problem soon. Though it's not a show stopper :-)

[tksoh]

I tried to benchmark other editors (Qt Creator, notepad, notepad++ and visual studio code) to see how they handle the situation as we scroll to the final line of the text area.

The first three would constantly try to fill the text area, but leave a pretty large gap (equivalent to the height of almost two lines) below the last line, so when we drag the bottom edge of the window down, they will uncover the lines at the top gradually, but always maintain that ~2 lines of empty space. I guess this is how they got around the problem.

VS Code simply scrolls all the way down until we only see the one and final line at the top of the text area, so it doesn't bother to adjust anything as we drag the bottom edge down, hence is completely immune to the problem of line drawing issues the others have. This feels like cheating, but a reasonable one -- and it gets the job done ;-)

Perhaps this is something to learn from?