Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Word Wrap for Text Viewer and Editor
Project is part of Google_Summer_of_Code_2006
Student: Ahti Kitsik (ahti.kitsik@gmail.com)
Blog: http://ahtik.com/blog/
Mentor: Philippe Ombredanne
First "micro/alpha"-release is available at http://ahtik.com/blog/2006/06/18/first-alpha-of-eclipse-word-wrap-released/
Implementation notes -- developer-only reference SUMMARY
TextEditor
IDocument Represents text providing support for - text manipulation, - positions, - partitions, - line information, - document change listeners, - document partition change listeners
IDocumentInformationMapping
A IDocumentInformationMapping
represents a mapping between the coordinates of two
IDocument
objects: the original and the image. The document information mapping
can translate document information such as line numbers or character ranges given for the original into
the corresponding information of the image and vice versa.
ITextStore Storing and managing text.
ILineTracker Maps character positions to line numbers and vice versa.
IDocumentAdapter Adapts an org.eclipse.jface.text.IDocument to the org.eclipse.swt.custom.StyledTextContent interface. The document adapter is used by org.eclipse.jface.text.TextViewer to translate document changes into styled text content changes and vice versa.
- How to store wrapped and unwrapped line number information about the same document? ***
Both of these are required: Wrapped line information is for the text viewer, code navigation, vertical column annotations. Unwrapped line information is required for functionalities like goto line, line numbering ruler column, current line
highlight.
Creating IDocumentAdapter that supports word wrap would fix TextViewer to support wrapping.
But as wrapping is only visual then all related ruler columns like annotations, line numberings etc fall apart.
LineNumberRulerColumn is currently using following to paint line numbers
for (int line= visibleLines.getStartLine(); line < lastLine; line++) {
int widgetLine= JFaceTextUtil.modelLineToWidgetLine(fCachedTextViewer, line);
if (widgetLine == -1) continue;
int lineHeight= fCachedTextWidget.getLineHeight(fCachedTextWidget.getOffsetAtLine(widgetLine)); paintLine(line, y, lineHeight, gc, display); y += lineHeight; }
This logic could be patched by following to support word wrap:
int lastWidgetLine=-1; int lastLineNumber = -1; for (int line= visibleLines.getStartLine(); line < lastLine; line++) { int widgetLine= JFaceTextUtil.modelLineToWidgetLine(fCachedTextViewer, line);
if (widgetLine == -1) continue;
int lineHeight= fCachedTextWidget.getLineHeight(fCachedTextWidget.getOffsetAtLine(widgetLine));
if (lastWidgetLine==widgetLine) { paintLine(lastLineNumber, y, lineHeight, gc, display); } else { paintLine(line, y, lineHeight, gc, display); lastLineNumber=line; } y += lineHeight; }
JFaceTextUtil.modelLineToWidgetLine(...) is becoming responsible for returning same line number for multiple lines
that form one wrapped line.
JFaceTextUtil.modelLineToWidgetLine(...):
public static int modelLineToWidgetLine(ITextViewer viewer, final int modelLine) { int widgetLine; if (viewer instanceof ITextViewerExtension5) { ITextViewerExtension5 extension= (ITextViewerExtension5) viewer; widgetLine= extension.modelLine2WidgetLine(modelLine); } else { IRegion region= viewer.getVisibleRegion(); IDocument document= viewer.getDocument(); try { int visibleStartLine= document.getLineOfOffset(region.getOffset()); int visibleEndLine= document.getLineOfOffset(region.getOffset() + region.getLength()); if (modelLine < visibleStartLine || modelLine > visibleEndLine) widgetLine= -1; else widgetLine= modelLine - visibleStartLine; } catch (BadLocationException x) { // ignore and return -1 widgetLine= -1; } } return widgetLine; }
!!! StatusBar is showing cursor position correctly (2:34) even after patching DocumentAdapter to support word-wrap! Also Goto Line works correctly!
Patching DocumentAdapter seems to be not enough to keep editing functionality. Keyboard navigation seems to be
tracked somewhere else (inserts usually work but do not redraw all affected areas).