Community
Participate
Working Groups
Build Identifier: I20100608-0911 The TreeLineTracker of a document breaks (that is, the line information is no longer consistent) when part of a line delimiter is replaced. I stumbled across this bug when working with my own content assist proposals, which performed a document#replace as described below. Such a replace will make most editor functionality broken (drawing, undo/redo, content assist, etc.). Reproducible: Always Steps to Reproduce: org.eclipse.jface.text.Document document = new org.eclipse.jface.text.Document("line1\r\nline2"); assert(document.getDefaultLineDelimiter().equals("\r\n")); assert(document.getNumberOfLines() == 2); assert(document.getLineInformationOfOffset(0).getLength() == 5); document.replace(5, 1, "XXX"); // TreeLineTracker doesn't handle this properly... assert(document.getLineInformationOfOffset(0).getLength() == 5+3); //... and now line information is broken The last call returns 7 and not 8, because the TreeLineTracker thinks the character that was replaced was part of the "pure length" of line, but instead it was part of the line delimiter that was replaced.
See bug 130843 comment 11: it's too expensive to always repair the document line information because that's not a normal use case. If one writes code that has the danger of doing this, then one can first call org.eclipse.jface.text.IRepairableDocumentExtension.isLineInformationRepairNeeded(int, int, String) which would tell whether one has to repair the line information afterwards.
I see, that makes sense. (I did wonder if isLineInformationRepairNeeded was related to this issue, but I disregarded it because it was only used by FindReplaceDocumentAdapter.) As things stand, I'll leave only the suggestion that, since IDocument#replace does not guarantee that the line information remains valid, this should be stated in IDocument 's documentation.
> As things stand, I'll leave only the suggestion that, since IDocument#replace > does not guarantee that the line information remains valid, this should be > stated in IDocument 's documentation. Good point.
Fixed in HEAD (Document.java rev. 1.19). Available in builds >= I20101027-0800.
Verified in I20101028-1800.
