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.
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: @Override 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.
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.
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.
Tim feel free to apply the patch. Thanks
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.
I would love to apply the patch, but until http://www.selenic.com/mercurial/bts/issue1003 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...
I will apply it.
applied in jet-main changeset: 128248:35c4e10482ac
There seems to be a minor regression caused by this patch, see issue #165168.
Should I revert this patch?
It's just minor regression - I do not think we need to revert the patch, but would be nice to fix it of course ;)
Issue #165175 is another minor regression...
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.
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).
Note issue #173114 , suggesting how to deal with yet remaining part of this problem.