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.
And here is the circumstance: * open a java file * create new empty line and move caret to the line * press TAB and then HOME Now if you press TAB again you will see that it has no effect - the caret is still at the beginning of the line and no tab was inserted. (Build 200303131400, Windows 2000, 1.4.1_01)
Feel free to decrease priority to P4-5 if this is only circumstance under which the problem is reproducible.
I am seeing this all of the time with a different key sequence and it is very fustrating. I get the same type of problem if I do the following: 1. Type a method header example: <tab>public foo(){ 2. Then press <enter> twice 3. Then close the method with a } 4. Press up arrow to position the caret to start typing code within the curly braces. 5. Press <tab> again to do the inital indent in the method.... NOTHING happens when <tab> is pressed (no matter how many times it is pressed). NOTES: - I'm seeing the <tab> not responding when I do a few other keystrokes too. - I have reproduced this on several machines, and several other developers have complained about this so I thought it would bump up the priority to P2
*** Issue 33441 has been marked as a duplicate of this issue. ***
I agree it's an annoyance and probably also a regression since 3.4, but sorry, the bug does not qualify as P2. Checkout the bug priority guidelines at: http://qa.netbeans.org/processes/bug_priority_guidelines.html
I think it's a P2 bug - please note: the 3.5 release is a special release for a better usability. The main problem is: You have a typical structured code like this: if ( foo.equals (bar) ) { for ( int i = 0; i < bar.length(); i++ ) { doSomething(); } | // ^- for empty lines, netbeans creates spaces for // the indent-level if ( somethingElse() ) { doOtherThings(); } } The user does not see the leadings spaces and can't jump with TAB to the indent level. This is frustating and should be fixed for 3.5. The source code editor is the main component of netbeans. This component should work without backward step in relation to older version. And yes, IMHO, it's a "critical usability problem" = P2-Bug greeting, josh.
I would have to agree with Aljoscha Rittner. This IS a P2 critical bug. My developers and I see this on a daily basis and it very much causes fustration when coding. I would have to agree that Netbeans editor is the PRIMARY component of the software, and should not allow itself to take a step backwards. Also... who has the power to change it back to Target:3.5 and Priority:P2?
Additional Comments: Jan Chalupa, You mentioned that "this bug does not qualify as P2"... I believe that it IS a priority 2 bug. As stated in the Bug Priority Guidelines... "P2 -product feature is significantly affected, a workaround may exist bug is difficult to use or impractical (KEY WORD DIFFICULT TO USE)..... -critical usability problem" Because of this bug it IS difficult to use the product (Hit TAB and the editor does not respond), and it DOES pose a critical usability problem (I can't just code freely with-out bumping into this bug). I believe that Netbeans is the best IDE out there, but when the main component of the IDE (ie the editor) stop working like it should (this bug was never a problem in prior versions), I think everything should be done to see that issues like this are NOT allowed to be present (not even for 1 release).
Ok, you conviced me. Raising back to P2. Mila, Mato, please try to investigate and see if a low risk fix can be found for 3.5. Re Jeff: Technically, anyone can change the priority and target milestone values, Issuezilla doesn't prevent it. In practice, target milestones should be set by the issue onwer only. Anyone is free to set the priority as a hint, but the module owner and QA (me :-) should agree with the final priority level.
I'm not sure this was mentioned here or whether it is related to this issue: other slight change in behaviour of TAB is that selecting a text and pressing the tab _indents_ the lines with selection. This definitely in the past _replaced_ the selection with one TAB character. I'm quite used to it and new behaviour always surprise me. :-)
I've found the reason why the bug happens: Excerpt from http://www.netbeans.org/issues/show_bug.cgi?id=21106 follows: Optimized the replacing of indent - now the removals of the original indent chars are only done if the new indent does not start or end with these old indent chars. I have a possible fix but I need to test it thoroughly and also investigate David's additional comment.
Regarding David's note I've checked older revisions and it works the same way like in release35 so there should be no regression although I agree that the behavior may look strange especially when pressing TAB for single-line interior selection. In such case it would be much more natural to replace selected text by tab (or spaces) rather than shifting whole line. Added enhancement http://www.netbeans.org/issues/show_bug.cgi?id=33638 for that.
Fixed in maintrunk: Checking in libsrc/org/netbeans/editor/BaseKit.java; /cvs/editor/libsrc/org/netbeans/editor/BaseKit.java,v <-- BaseKit.java new revision: 1.89; previous revision: 1.88 Visual diff at http://www.netbeans.org/source/browse/editor/libsrc/org/netbeans/editor/BaseKit.java.diff?r1=1.88&r2=1.89 The fix sets caret position manually after indent of the line gets changed. Mato, could you please review the fix? Thanks.
Created attachment 10310 [details] Binary patch for release35 - please copy classes from attached jar into nb-editor.jar
Marking as fixed.
The fix is OK.
Verified patch in NB 3.5 RC1 build 200304282350.
The fix should go into release35 -> P1.
approved for 3.5
Merged into release35: Checking in libsrc/org/netbeans/editor/BaseKit.java; /cvs/editor/libsrc/org/netbeans/editor/BaseKit.java,v <-- BaseKit.java new revision: 1.86.2.3; previous revision: 1.86.2.2 done
Thanks for the fix!!!!!!!!!!! Netbeans rocks!
Great and thanx!