Page Up/Down interval

[Tim]

> What might look to you as a two line overlap

Uh, I said "short by one line".

OK, fine. The point remains that our design allows the bottom line in the window to be partially obscured, possibly only a pixel or two. Obviously we need to show the partial line after a Page Down. Our choice is to overlap by a whole line plus the partial line. Say we eliminated the whole line overlap. If someone were counting on seeing each line only once while paging down, they would need to be sure that the window size didn't cause the last line to be clipped by even one pixel.

The only way to properly support seeing each line once is to show only whole lines in the display.

[chrisjj]

> The only way to properly support seeing each line once is
> to show only whole lines in the display.

Sounds good to me.

[Michael Bulgrien]

Michael, I think you, chrisjj, and RunnerBike are all suggesting different things...

Yes, you're right Tim. And my apologies to chrisjj for railroading his thread and taking it off-topic.

The one change I'm considering is that subsequent presses of Ctrl+PgUp/Ctrl+PgDn will scroll, like you described in post #5.

Thanks for considering it.

Regarding chrisjj's concerns, I would suggest a tweak that auto-adjusts the pane height to be an exact multiple of the line height so that you can avoid overlap/partial lines without having to change your default functionality. Not the most graceful implementation, perhaps, but it should work. I've done similar things (auto-resizing) in graphical user interfaces in the past.

[chrisjj]

> Regarding chrisjj's concerns, I would suggest a tweak that auto-adjusts the pane height
> to be an exact multiple of the line height

If you mean fighting/disprespecting the user's drag, then please no. Far better I suggest is for the pane just to /show/ only whole lines. A part-line's worth of white at the bottom isn't going to hurt anyone.

[Michael Bulgrien]

Well, you're right, Chris. It wouldn't work that well, would it?

In my opinion, I like the fact that BC lets you see partial lines at the bottom of the screen. What feels odd to me is that it is not the partial line at the bottom of the screen that scrolls to the top of the screen, it is the line before it. In my opinion, it would be better if the partial line would scroll to the top of the screen instead of the last full line.

When there is a full line at the bottom of the screen (no partial line) then it is a matter of preference whether it scrolls to the top or whether the next line is scrolled into view. I certainly don't see why that can't be a configurable option and, in this case, have to disagree with Tim when he says, "Eliminating the overlap only makes sense if the window displays whole lines and not partials."

If the user has the BC window sized such that a full line (or a pixel or two more) exists at the bottom of the display then it should not be difficult to eliminate the visual overlap. Partial lines scroll to the top. Full lines scroll off the screen. That's all there is to it.

[Michael Bulgrien]

> Many (most?) editors overlap on page up/down.
UE12 and UE15 don't overlap.

If this feature will make it in a future release of BC3 I suggest make it a tweak where the user can select the number of lines to overlap at page up/down (0..oo).

More thoughts on this... if you don't want to make it configurable as Lutz suggested, then setting it up like I've described in the previous post (last full line scrolls off the screen on scroll) is the next best thing. Users that want to see an overlap can set the BC pane size so that the last line is a pixel or two short of a full line. This will cause the line to re-appear at the top of the screen on a scroll. Users that don't want overlap can set the last line to a full line (or a pixel or two more).

If a tweak were added (as Lutz suggested) then it could simply equate to how many more lines to offset than the default (i.e. how many full lines to retain with the default being zero).