Menu

Vertical scrolling below last line impossible

koyama
2008-01-10
2012-11-13
  • koyama

    koyama - 2008-01-10

    I suggest altering the vertical scrollbar, making it possible to scroll vertically downwards below the last line so bottom lines can be viewed at a pleasant height.

    At it is now, for text files that occupy more than the height of 1 screen, I am forced to view the lower lines at the bottom of my screen. For me, this makes editing less pleasant because usually want to look at the lines that I am editing in the upper half of the screen. I know I can just add say 50 empty lines at the end of the file. Then it will be possible to scroll further down. But having to add white space in the file is obviously not always desirable.

    For comparison, UltraEdit-32 has implemented vertically scrolling so that one can always scroll downwards and get the bottom line to the top of the editing window.

     
    • koyama

      koyama - 2008-01-12

      > I guess you only say this because _you_ want this implemented, and not,
      > as you kind of say, the whole world. If the need for this feature is
      > justified by its presence in other applications, then your arguments
      > don't really add something.

      I admit that my arguments are vague. The reason why I am pointing at UltraEdit is because I think their solution shows that they indeed have been trying to deal with the usability issue that I am claiming exits in Notepad++. Naturally, I wouldn't suggest altering Notepad++ to suit only my needs if it is just me who is abnormal.

      Note that I agree with you that Notepad++ is dealing with the vertical scrollbar in a technically consistent manner. My objection is only usability-related.

      As a thought experiment, if Notepad++ extended the scroll range, would you then make use of it? Would others? To find out ask some people to open a long document in UltraEdit and add some words after the last line and observe the vertical position while they are editing. If the outcome is that they all are editing the line with cursor position at the bottom of the window then my idea of typical user behavior is incorrect. My own editing method is scroll-type-scroll-type... keeping last line at some distance from the bottom. But this technique is not possible in Notepad++.

      > I believe you consider it a need for a file of only one line to have
      > a scroll bar of half the height of the window to allow to move that line
      > to the bottom and back to the top. Does this make sense?

      No, I am no suggesting this. Top position of vertical scroll bar should imply that first line is aligned at the top. Like it is now.

       
    • Nobody/Anonymous

      I always wonder why there isn't a similar possibility to scroll the top line down, for the same reason.

       
    • koyama

      koyama - 2008-01-10

      Yeah, the thought occured to me while I was writing the post. I strongly agree with you that it would enhance usability if one could get any line (including the top lines) to be at any height on the screen. This may seem like a small thing, but sometimes it is such tiny things that make a big difference.

      The challenge with your suggestion may be to find a solution how to design the interface so scrolling upwards above the top lines will be possible. I haven't thought about it, but I don't know of any text editor with this possibility.

      Thanks for your reply. I was not able to find any posts dealing with this issue, so I was unsure whether it was just me who was strange.

       
      • Nobody/Anonymous

        I merely meant this as I kind of joke. I don't really see the point in trying to move a line to the middle of the screen to get a better focus, if it's on the edge of the file. I suggest you just make your window smaller then.

        There are some applications which do allow scrolling beyond the last line of the document on the last line of the window. The size of the scroll bar may be a "problem" here. I think it normal to expect the size of the scroll bar to reflect the relative size of the visible part of the document as opposed to the available scrolling space. This means you can't scroll beyond the end of the document or above its top by using the scroll bar.

        The applications I know allow pressing the arrow buttons above and below the scrolling space to go beyond that limit. The result will be the scroll bar getting smaller and being smallest when only the top or bottom line is visible. (Actually, they don't allow scrolling up, I mention it just to be consistent.) If the scroll bar gets smaller, of course its size isn't relative anymore to the real number of lines the document contains.

        Allow this scroll-beyond-extremes functionality requires the scroll bar size to be adjusted when it is being used or when it is left, that is, when the user scrolls back to a "normal" position, either by dragging it or clicking above or below the bar. This may have an impact on performance, although I don't see this in the application I use.

         
        • Nobody/Anonymous

          I notice scrolling beyond the last line is also possible in the diff tool that comes with Tortoise SVN. This does not adjust the size of the scrollbar, so it will still reflect the size of the window pane relative to the file, but then, of course, it doesn't correctly reflect the position in it (it doesn't move anymore).

           
    • Nobody/Anonymous

      Scintilla natively supports scrolling one page below the last line, although in Notepad++ this is turned off (the scrollbar probably adjusts to that automatically). It may be a small help to select the very last line, but it makes ensuring your file has a newline at the end more difficult. As always, it probably ends up being a personal preference if it being turned on or off (if you read in the forums you see many (heated) discussions about things being not the way they should be or being changed into something not as it should be, with a few replies stating it exactly IS as it should be). An option may be, well, an option, but having too many options doesn't make life much easier, is error prone and maybe confusing.

      On a side note, there always the Feature Requests tracker, I think that works more effectively that posting it in the forums as it allows the maintainer to very clearly state if it is going to be denied or if it is considered. Also, if you log in you get this nice automated email if anything changes about the request :).

      -Harry

       
    • koyama

      koyama - 2008-01-11

      > I suggest you just make your window smaller then.

      This does ensure that I can edit the bottom lines at a higher position on the screen. But I would still like to *view* as many lines as possible of the file — even at the bottom of the screen. There is a difference between editing and viewing a line. Editing requires stronger focus than viewing. It is hard to keep focus on a line at the bottom of the screen. Not only because of low position, but also because adjacent task bars are rather distracting.

      > There are some applications which do allow scrolling beyond the
      > last line of the document on the last line of the window. The size
      > of the scroll bar may be a "problem" here. I think it normal to expect
      > the size of the scroll bar to reflect the relative size of the visible
      > part of the document as opposed to the available scrolling space.

      You do have a point. However, I don't think we should worry too much about whether the height of the vertical scrollbar exactly reflects the relative size of the visible part of the document or not. I believe the vertical scrollbar's most important function is the ability it gives users to — well — scroll. The height is less important. Anyway, even if one introduces whitespace below last line (adding to effective document height), then the difference between the two vertical scrollbar heights becomes negliable for files extending more than a couple of screen heights.

      > The applications I know allow pressing the arrow buttons above and below
      > the scrolling space to go beyond that limit. The result will be the scroll
      > bar getting smaller and being smallest when only the top or bottom line is visible.

      > I notice scrolling beyond the last line is also possible in the diff tool that
      > comes with Tortoise SVN. This does not adjust the size of the scrollbar, so it
      > will still reflect the size of the window pane relative to the file, but then,
      > of course, it doesn't correctly reflect the position in it (it doesn't move anymore).

      Personally I'm not too keen on those solutions. I prefer that arrow down cannot be activated when the scrollbar is at the bottom. Otherwise you will see a discontinuous jump of the document downwards when you first force-scroll using arrow-down and thereafter activate ordinary scrollbar. This is a drawback with the diff tool (although their intention is good). Therefore I'd rather prefer UltraEdit's solution. Here they add exactly one-screen height of scrollable whitespace below the last line. Therefore there is no need to force-scroll via arrow-down button. Notice in the diff tool of Tortoise SVN they do add approximately 6 lines of scrollable whitespace below the last line which is good. Therefore even without the arrow-down button the last line does not stick all the way down at the bottom.

      > Scintilla natively supports scrolling one page below the last line, although
      > in Notepad++ this is turned off

      Thanks for the information. Sounds like this corresponds to the behaviour I'm seeing in UltraEdit. Together with all the other examples plus my arguments, I think this is an indication that there *is* need for such a feature. If there was no need for such a feature vendors wouldn't have bothered to implement the technically more difficult solution.

      > On a side note, there always the Feature Requests tracker, I think that works
      > more effectively that posting it in the forums as it allows the maintainer to
      > very clearly state if it is going to be denied or if it is considered.

      Thanks, I'm new to this forum so I didn't know. I think I'll wait and see what kind of responses I get here. If noone has any serious objections against my suggestion I'll try posting this as a feature request.

       
      • Nobody/Anonymous

        > Thanks for the information. Sounds like this corresponds to the behaviour I'm seeing in
        > UltraEdit. Together with all the other examples plus my arguments, I think this is an
        > indication that there *is* need for such a feature. If there was no need for such a
        > feature vendors wouldn't have bothered to implement the technically more difficult
        > solution.

        I guess you only say this because _you_ want this implemented, and not, as you kind of say, the whole world. If the need for this feature is justified by its presence in other applications, then your arguments don't really add something. Next to that, a lot of applications contain features that are not really needed. If this was, then why isn't it present in any application?

        I believe you consider it a need for a file of only one line to have a scroll bar of half the height of the window to allow to move that line to the bottom and back to the top. Does this make sense?