Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
9.0
Description
The NetBeans editor's word wrap feature, which can be enabled via Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few quirks that makes wrapped text hard to read. I have prepared a patch which makes the following improvements, as illustrated in the attached before/after screenshot:
1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to split text instead of the previous hand-coded text wrapping logic (this was in fact suggested as a TODO in the previous code). This, in particular, avoids putting spaces and punctuation at the beginning of a wrap line, making the NetBeans editor work more like other editors. This fixes the BugZilla bug 242113.
2) Handle words that are longer than the preferred maximum width properly. The long word still won't be broken, but at least the rest of the paragraph will--previously the entire rest of the paragraph would remain unbroken in this case.
3) Allow whitespace at the end of a wrap line to extend beyond the preferred viewport width (like in jEdit and other editors, including the in-browser editor I'm typing this JIRA issue description in). This usually saves one character of horizontal space for regular text paragraphs.
4) Don't display a "line continuation character" to indicate that a line has been wrapped. It clutters the display, takes up an extra character of horizontal space, and does not work well with rule (3) above. Besides, in the NetBeans code editor, the equivalent information is already communicated to the user by the line numbering to the left. This fixes the BugZilla bug 213829.
Besides improving the word wrap feature for use in the NetBeans editor, this patch also makes NetBeans' EditorKit more useful for standalone use in a JEditorPane, e.g. in NetBeans Platform applications. For instance, my own platform application uses NetBeans' EditorKit to provide editing of text paragraphs and spreadsheet formulas in a spreadsheet-like table widget, where horizontal space is at a premium.
Note that word wrapping boundary computation logic exists in two different places in the editor.lib2 module: in o.n.modules.editor.lib2.view.HighlightViewUtils.breakView , and in o.n.modules.editor.lib2.view.WrapInfoUpdater.getWordInfo. The logic changed in this patch is that of HighlightViewUtils.breakView. The WrapInfoUpdater.getWordInfo routine seems to be a fall-back path that is only used for View implementations that do not use HighlightViewUtils.breakView, or when the latter fails. I was never able to make WrapInfoUpdater.getWordInfo return non-null during a real editor session, having tried word wrapping in Java source files, including with collapsed methods (which I know involves a special kind of View), and selected text (to try to trigger the old BugZilla bugs 183219 and 189554, which were mentioned in the commits around the related code in WrapInfoUpdater). To avoid breaking things, I have not changed the logic in WrapInfoUpdater.getWordInfo. Miloslav Metelka might be able to tell whether the latter is really "dead code" or not.
Attachments
Attachments
Issue Links
- links to
