Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
9.0
Description
Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor.
Specific bugs:
1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line).
2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line.
3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position.
4) Pressing Down will move the caret down two lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough).
5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line.
The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction).
Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move the caret before lineStartPos.)
Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With NetBeans' current behavior, this space corresponds to a caret position directly following the last character of a wrap line. This caret position, however, is physically mapped (and painted) on the beginning of the following wrap line, which confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then bugs 2-4 might "fix themselves" as well.
For bug 5, I think the best solution when clicking the space beyond the end of a wrap line would be to move the caret to right before the last character on the wrap line. This character is usually a space (in word wrap mode), though it could also be a hyphen or such if a more advanced word wrapping algorithm is used (proposed in the pull request for NETBEANS-977). The resulting behavior would be similar to that of a default JTextArea, or jEdit (though these never break words on anything else than a space). Another solution would be to do like the TextEdit app on MacOS, where the cursor is placed after the last character on the wrap line, like NetBeans currently does, but with a backwards bias such that the cursor is painted on the end of the current wrap line instead of on the beginning of the next wrap line. The latter is probably harder to implement, and is not really necessary.
To test the above bugs:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and paste in the paragraph "SHORTWORD LOOOOOOOOOOOOONGWORD SHORTWORD LUUUUUUUUUUUNGWORD".
3) Resize the editor window so that the paragraph gets split into four wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word).
4) For each bugs 1-4 listed above, position the caret right after "...OOOOONG", then press the relevant key to test.
5) To test bug 5 above, click the mouse to the right of the first, second, or third wrap line.
Tested in NetBeans 9.0 rc1.
Attachments
Issue Links
- is duplicated by
-
-
- Closed
-
- links to
