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.
[NetBeans 200512011936; FC4; JDK 1.6.0-b59] Issue Summary: -------------- Editor opens on wrong position when you use navigation (e.g. navigator or hyperlinking). Caret is on last line so the user doesn't see the whole context of code. This is a regression against NetBeans 4.1. Steps to Reproduce: ------------------- 1. Create a new class, e.g. TestClass. 2. Create a method public String test(). 3. Add 40 empty lines before the test() method. 4. In constructor, type test() and use hyperlinking to jump to the method. -> The test() method is opened on last line in editor.
P2 because it is a regression decreasing usability.
This is physically caused by fix of issue 61103, but the real problem is that in the past the BaseCaret.setDot(int offset) was doing something extra over the basic contract of the Caret.setDot(int offset) which is to just position the caret to the given offset and ensure that the caret will be visible (but not that the caret will be positioned in the middle of the window). If the client of setDot() needs a specific positioning of the editor view e.g. to have as much as possible code visible for the given method then it should ensure that by itself. It has the best knowledge of what should be visible and the original code in the BaseCaret.setDot() cannot do exactly what's necessary anyway because the only information that it has is the integer offset which is not enough information in this case. For example consider that in 4.1 if you have the window positioned so that the method (that you later double-click in the Navigator) has the signature visible on the last line of the window then the caret only jumps to the last line (not scrolling the window so that the method is in the middle of the window). If the client (Navigator) would care then it could scroll the window so that whole (or at least part) of the method would be visible. Anyway as it's late in the release cycle I'll attempt to find a reasonable fix on the editor side that will restore the original behavior.
I thought it is driven by Scroll Find/Jump Insets. Anyway Scroll Find Insets don't work. If it is not related, we should file a new issue.
Fixed in trunk: Checking in libsrc/org/netbeans/editor/BaseCaret.java; /cvs/editor/libsrc/org/netbeans/editor/BaseCaret.java,v <-- BaseCaret.java new revision: 1.122; previous revision: 1.121
The scroll jump insets will no longer apply. The option was there due to slow scrolling in early jdks but now it's not necessary when the blit scrolling mode is available. The users were complaining that the scrolling is "jumpy" due to this setting so it's desirable to get rid of the option and just scroll smoothly with the caret still on the last line. Regarding scroll find insets I've entered issue 69941.
Verified in build 20051207-0700.
*** Issue 69547 has been marked as a duplicate of this issue. ***