Announcement

Collapse
No announcement yet.

Page Up/Down interval

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • chrisjj
    started a topic Page Up/Down interval

    Page Up/Down interval

    Could the Text Compare Page Up/Down interval be a full
    page, please? Here (41 lines per page) it is short by one line.

    (Which is better than BC2's two).

    Showing the same line on two successive pages can mislead.

    Thanks.

  • Michael Bulgrien
    replied
    Originally posted by Lutz View Post
    > 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).

    Leave a comment:


  • Michael Bulgrien
    replied
    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.
    Last edited by Michael Bulgrien; 01-Jul-2009, 04:52 PM.

    Leave a comment:


  • chrisjj
    replied
    > 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.

    Leave a comment:


  • Michael Bulgrien
    replied
    Originally posted by Tim View Post
    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.

    Originally posted by Tim View Post
    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.

    Leave a comment:


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

    Sounds good to me.

    Leave a comment:


  • Tim
    replied
    Originally posted by chrisjj View Post
    > 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.

    Leave a comment:


  • chrisjj
    replied
    > 1) Eliminating the overlap only makes sense if the window
    > displays whole lines and not partials.

    Disagreed. Eliminating whole-line overlap makes sense regardless.

    > We can post this to the wishlist,

    Thanks.

    Leave a comment:


  • Tim
    replied
    Michael, I think you, chrisjj, and RunnerBike are all suggesting different things. Here are my thoughs on the comments:

    1) Eliminating the overlap only makes sense if the window displays whole lines and not partials. We can post this to the wishlist, but I doubt that we will change BC's behavior or offer a tweak anytime soon.

    2) PageUp/PageDown keep the cursor at the same position relative to the top of the window. Most of the text editors we use for comparative testing do this. I don't agree that this causes the user to lose his or her place.

    3) Ctrl+PgUp/Ctrl+PgDn move the cursor to the extents of the window. Most editors of the editors we use for comparative testing do this.

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

    Leave a comment:


  • chrisjj
    replied
    > What might look to you as a two line overlap

    Uh, I said "short by one line".

    Leave a comment:


  • Michael Bulgrien
    replied
    Originally posted by Tim View Post
    Notice also that UE does not show partial lines at the bottom of the window, like BC and many other editors do. It would be impractical to show partial lines and not have an overlap.
    Tim, I didn't suggest that you change the default functionality. I suggested that you make the option available to those that would prefer it... whether it be via a tweak, a configurable option, or assigned to currently unassigned keyboard accelerators. The fact is that the ability to scroll without losing your place in a compare/merge session would be extremely useful.

    Leave a comment:


  • Tim
    replied
    Originally posted by chrisjj View Post
    The overlap of my report was of full not partial lines.
    What might look to you as a two line overlap is actually one line plus a partial. The 2nd line would be missing at least one pixel in height.

    Leave a comment:


  • chrisjj
    replied
    Originally posted by Tim View Post
    It would be impractical to show partial lines and not have an overlap.
    The overlap of my report was of full not partial lines.

    Leave a comment:


  • Tim
    replied
    Originally posted by Lutz View Post
    > Many (most?) editors overlap on page up/down.
    UE12 and UE15 don't overlap.
    I believe UE was the only editor we tested that doesn't overlap. Notice also that UE does not show partial lines at the bottom of the window, like BC and many other editors do. It would be impractical to show partial lines and not have an overlap.

    Leave a comment:


  • Michael Bulgrien
    replied
    FYI - UltraEdit uses Alt+PgUp and Alt+PgDn to place focus on the first or last visible line on the screen (without scrolling).

    Since Ctrl+PgUp and Ctrl+PgDn already retain focus when paging, perhaps the option to stop with the currently selected line at the top or bottom of the screen would be more appropriate on these keypresses.

    Leave a comment:

Working...
X