TextRectangle bug

A tiny but annoying bug I just found...

If you specify a negative parameter for bottom (so it will count from the bottom) and have the distance between the actual window and the output area as being less than the height of the font, it will go wonky when using pageup/pagedown with scrolling down: it never wants to fully scroll down (thumb on scrollbar stays one pixel above the fully scrolled down position) and the MORE indicator always stays on.

Atleast, I think it has to do with fontheight, since the bug happens for me around sizes below 23 pixels height... which approximates my fontheight.

Figures, and now I can't reproduce it anymore all of a sudden.

Probably the amount of data in the buffer also factors into this somewhere.

/me is off to test a bit more.

Edit: Oops, accidentally posted a second time rather than edited. Anyhow, it's confirmed. Clearing my outputbuffer made the bug show again. It's unlikely to show for sufficiently large outputbuffers - my outputbuffer was +- 300 lines when it stopped happening, but it is annoying none the less. =)

It doesn't surprise me, I am surprised not more things went wrong, after all those changes for the TextRectangle.

I'll try to find and fix it for the next version.

I can't reproduce it - can you be specific about the exact font you are using and the exact height of the text rectangle? Or, the exact script call? Maybe the width of the border affects it.

I am using Monaco, 9pt as font. The code I used was this (or atleast I think so - I don't really recall playing with it much more than that (just done with 48 hours of travel and my mind is a blank atm.)

Hmm, I don't seem to have Monaco 9 pt, but using Dina 9 pt and the code you gave above, doesn't cause any problems for me.

I got the font quite some time ago from this site: http://www.lowing.org/fonts/. I doubt the font changed though.

If you can't get it working after that, I'll see if I can recreate the bug again somehow.

I just managed to reproduce it... with TextRectangle() being called to cover the entire window, and while having plenty of scrollback. I'm flabbergasted. Basic way to trigger it for me so far seems to consist of:

- Have a TextRectangle which doesn't reach the bottom of the output window.
- Get some content in.
- Change the TextRectangle so that the bottom edge of the TextRectangle and the bottom edge of the output window becomes smaller. I do this atm by resetting the TextRectangle to the default.
- Notice a gap of space below all the output so far.
- Now click the bottom arrow of the scrollbar - it will jump UP and make the actual last line go at the bottom of the output area, hiding the gap of space. The MORE INDICATOR is on.
- Now grab the thumb of the vertical scrollbar, drag it up a bit and make the output window scroll, and now drag it all the way back down - and the gap is back from it's hidey spot.
- Any new input apparently recalculates the size of the internal buffer, so one more line (no matter how small compared to the gap) fixes it. My guess is that the code to calculate the visible area of the output calculates until the bottom of the output window, rather than the TextRectangle() - ending up with a value that isn't correct and messes up the MORE indicator and the scrollbar.

Screenshot: hxxp://qs.merseine.nu/images/textrectangle_gap.png. Replace the hxxp by http. =)


Also, I found something else that is affected by TextRectangle. The Find function fails to actually draw the selection on the found word when:

- the TextRectangle() does NOT cover the full output window
- AND the found text can be seen WITHOUT scrolling.

It seems a redraw can be focused by clicking on the scrollbar. Clicking in the outputwindow outside of the TextRectangle doesn't help, however.


Last.. which may or may not be a bug. It might have been there already in the past prior to TextRectangle(), but the fact I can make nice borders makes it show up far more than it used to in the past. Suppose I select a few lines of text, then use CTRL+UP to scroll up. Now I make the selection disappear out of view, with the last unselected line now being the bottom visible one. You'll notice a 1 pixel border at the bottom of the textrectangle, just below the last unselected line. You can also notice it by using background colors in notes and scrolling up like that.

What can I say... I'm OCD and notice little things. >_>

You forgot to mention that if you set a bookmark, and then go to that bookmark, and it is on the same screen, it also is not highlighted properly. :)

I never even use bookmarks. I thought I was already being a good tester, and here I get called out on doing an inadequate job. *sniffle*

See the release notes, points 21 to 24. All the things you mentioned are fixed.

The stuff about the 1 pixel border is, I think, because you have 1 pixel text offset set in the output configuration. It was in fact drawing two lines too many, thus you were seeing the start of the next line, including the inverted selection (which is normally in the output colour and thus not visible).

Your report alerted me to the possibility that other things that invalidate the selection might be wrong, which it was.

Aww, sometimes a textmedium can't convey humor too well. I'll add a smiley or two next time. :)

I got it - and I certainly appreciate the detailed testing. :-)

:O