This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 161700 - Constantly typing at the bottom of the screen
Summary: Constantly typing at the bottom of the screen
Alias: None
Product: editor
Classification: Unclassified
Component: Painting & Printing (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: David Strupl
Depends on:
Blocks: 165168 165175
  Show dependency tree
Reported: 2009-04-01 19:22 UTC by _ tboudreau
Modified: 2009-09-25 15:15 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2009-04-01 19:22:51 UTC
One problem I notice with our editor which does not seem to happen with IntelliJ IDEA is that I constantly find myself
typing on the last visible line on the screen.

This was not so much of a big deal when Ctrl-Up/Down would scroll the editor without moving the caret.  But now it is a
constant annoyance to take my hand off of the keyboard and use the mouse wheel to scroll so I can see a few lines below
what I am typing.  There is the added issue that it is simply more natural for a person to look at the middle of the
screen when editing something, rather than the bottom.

One of the reasons this happens is that newly generated code is often inserted at the end of the file.

Here is a simple fix for one part of this problem:  Make the preferred height of the editor pane such that it is always
possible to have the last line in the middle of the editor's scroll pane.  Override
org.openide.text.QuietEditorPane.getPreferredSize() as follows:

    public Dimension getPreferredSize() {
        //Avoid always typing at the bottom of the screen by
        //adding some virtual height, so the last line of the file
        //can always be scrolled up to the middle of the viewport
        Dimension result = super.getPreferredSize();
        JViewport port = (JViewport) SwingUtilities.getAncestorOfClass(
                JViewport.class, this);
        if (port != null) {
            int viewHeight = port.getExtentSize().height;
            if (result.height > viewHeight) {
                result.height += viewHeight / 2;
        return result;

I've been running with this patch for a while now, and so far, it definitely helps the problem.
Comment 1 Ondrej Langr 2009-04-02 09:49:02 UTC
Good catch! Agree this is a small enhancement with potentially large effect!

Just some ideas - in sequential editing (I know, this is a HUGE simplification, coding is by no means sequential, but at
least for some people, coding of an individual method or class is), the previous lines are more important than the
future lines, which mostly give you the clue where in the code you are and what is going to happen after the line which
you work at. 

What I'm trying to say is that keeping the active line in the middle of the screen does seems better than at the bottom,
but not entirely right. I'd suggest active line to be somewhere about 2/3 or rather even 3/4 of the visible area.
Comment 2 _ tboudreau 2009-04-02 17:38:56 UTC
2/3 or 3/4 is reasonable.

For some history, Borland Delphi had this weird editor mode where the caret line was *always* at the center - if you
pressed enter, the editor scrolled up.  That was a little too different from what anybody expects from an editor today.

But we could do a much better job keeping more content on screen.  Re Ondrej's comment about sequential, I think at
least in Java the issue is code *blocks* - that is, if I'm typing in a section beginning with a {, I am nervous if I
can't see the closing } - there may be code there, or the bracket may be missing, or something, but the point is, I
don't know what's there, so I will take my hand off the keyboard and scroll the editor so that I know what context I am
typing into.

In a perfect world, where it can fit on the screen, we would find a way to (undisruptively) make sure that the user can
see to the close of whatever code block they're typing into.  But that's probably a separate issue - just being able to
get the bottom line of the file closer to the middle of the screen helps a good deal.
Comment 3 Vitezslav Stejskal 2009-04-06 12:06:49 UTC
Tim feel free to apply the patch. Thanks
Comment 4 Miloslav Metelka 2009-04-06 14:58:46 UTC
Not sure whether it's a good idea to put this into 6.7 at this time but let's apply it an we will see.
BTW this is nothing new the previous versions of NB had a "virtualSize" that did the exactly same thing like your patch. There also used to be "Scroll Insets" 
and "Find Insets" for keeping some extra amount of lines at bottom/top of screen when scrolling/searching through the text. It got abandoned by getting rid 
of the Advanced options.
Comment 5 _ tboudreau 2009-04-09 18:48:35 UTC
I would love to apply the patch, but until is fixed I can't actually push
to the NB repository :-(

If you could take care of it, Vita, I will happily buy you a beer the next time I'm in Prague...
Comment 6 David Strupl 2009-04-22 14:46:23 UTC
I will apply it.
Comment 7 David Strupl 2009-04-22 16:00:22 UTC
applied in jet-main changeset:   128248:35c4e10482ac
Comment 8 Vitezslav Stejskal 2009-05-14 13:55:25 UTC
There seems to be a minor regression caused by this patch, see issue #165168.
Comment 9 David Strupl 2009-05-14 16:06:11 UTC
Should I revert this patch?
Comment 10 Marian Mirilovic 2009-05-14 16:48:58 UTC
It's just minor regression - I do not think we need to revert the patch, but would be nice to fix it of course ;)
Comment 11 Vitezslav Stejskal 2009-05-15 08:39:00 UTC
Issue #165175 is another minor regression...
Comment 12 mpalka 2009-07-10 19:06:10 UTC
Whenever you add this kind of improvement I think there should be a way to switch it off (an option in configuration). I
must admit I first thought of this one more as a bug than a feature. It just feels broken and messy when my vertical
scrollbar scrolls behind the last line of the file while navigation using arrow keys doesn't.
Comment 13 Ondrej Langr 2009-09-25 14:46:14 UTC
I feel there is a time to start discussion regarding this behavior again. While I agree this is a good thing to have, I
must backup a little bit in my previous enthusiasm and admit I misunderstood what this issue was expected to solve

I thought this issue was about the following situation:
I am editing somewhere in the bottom of the visible area (let's say 4 lines above the end of visible area). I write a
new method declaration and keep adding lines with code. At this point, when I reach the "fold" of the visible area, the
text is automatically scrolled so that I still keep typing on the last visible line in the editor. However, this
behavior did not change after this patch was integrated. Instead, I was given the possibility to *manually* scroll so
that I can see the extra space after the end of the file. Further, this new behavior does only address being able to see
empty space beyond the end of the file, but does not help me in any way in non-sequential editing. 

So while I agree that having a few empty lines to indicate the end of the file is useful, I think there is still large
area for improvement. 

mpalka: this patch introduced several regressions/bugs (for a good summary see issue #167628) which I believe can make
life worse to some people, but IMO, we should fix them and make the behavior feel "right" for everyone, instead of just
allowing to switch it off. Let's talk about this again after these regressions are fixed (if the need to switch this off
will still be there).
Comment 14 Ondrej Langr 2009-09-25 15:15:26 UTC
Note issue #173114 , suggesting how to deal with yet remaining part of this problem.