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.
Summary: | BaseDocument quirk causes New "Main" Template to be corrupted in the external editor | ||
---|---|---|---|
Product: | editor | Reporter: | Torbjorn Norbye <tor> |
Component: | -- Other -- | Assignee: | issues@editor <issues> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | issues, jchalupa, non_migrated_user, pkeegan |
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | Sun | ||
OS: | SunOS | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 14546 | ||
Attachments: |
Editor diff
Editor diff |
Description
Torbjorn Norbye
2001-10-27 02:22:22 UTC
I tracked this bug down to the fact that, in org.netbeans.java. codegen.CodeGenerator.clearBounds(), Element.getEndOffset() returns different values depending on whether the doc is a BaseDocument or an ExtEdDocument. Trace follows: [using java editor:] doc=org.netbeans.modules.editor.NbEditorDocument@f1735, kitClass=class org.netbeans.modules.editor.java.JavaKit, docLen=341, bounds=Position bounds[Pos[64],Pos[90],"package Templates.Classes;"] calling doc.remove(64,26) lineRoot=org.netbeans.editor.BaseDocument$LineRootElement@2d3de line=getStartOffset()=64, getEndOffset()=64, getParentElement()=org.netbeans.editor.BaseDocument$LineRootElement@2d3de lineIndex=6, p1=64, p2=64 calling doc.remove(64,1) clearBounds, lineIndex=6 doc.getLength() = 314 calling doc.remove(64,1) [using external editor:] doc=org.netbeans.modules.externaleditor.ExtEdDocument@f35d1, bounds=Position bounds[Pos[64],Pos[90],"package Templates.Classes;"] calling doc.remove(64,26) lineRoot=BranchElement(section) 0,304 line=BranchElement(paragraph) 64,65 lineIndex=6, p1=64, p2=65 calling doc.remove(64,2) clearBounds, lineIndex=6 doc.getLength() = 301 calling doc.remove(63,2) Notice that "p2" is different by 1 in these two cases. p2 is the result of calling line.getEndOffset(). "line" is obtained from "lineRootElement.getElement(lineIndex)". See the code near line 420 in clearBounds(). In the case of the java editor, the line bounds do not include the newline, whereas in the external editor case (derived from javax.swing.text.DefaultStyledDocument), they do. This results in clearBounds() deleting one-too-many characters twice, resulting in a mangled document. I tried making my own implementations of LineRootElement and LineElement, and managed to get New "Main" Template to work, but it broke nearly everything else. To properly emulate the (broken) behavior of BaseDocument would require re-implementing most or all of DocOp, DocMarks, Mark, and Line{,Root}Element. I believe that the proper fix is to make clearBounds() (and other places that examine document Element bounds) operate properly with a StyledDocument. This entails making BaseDocument behave like a StyledDocument and fixing up all references to Element.getEndOffset(). Alternatively, make BaseDocument (or its equivalent) usable as a base class by other modules, so I can base ExtEdDocument on it. I realize that this will not happen in 3.3.1, and probably not 3.3.2, but I'm hoping for 3.4. In 3.4 we will make the BaseDocument compatible with the Swing document implementations. This will include inserting of an extra '\n' at the content creation and it will also include offset-reset of the positions that once reach the zero offset. The BaseDocument.getEndPosition() will be also made swing-compatible. The BaseDocument will implement StyledDocument in 3.4. The line structure will be available under the paragraph root element. This should work fine assuming the javax.swing.text.Utilities.getParagraphElement() will be used (or the methods in org.openide.text.NbDocument that first call the findLineRootElement()). The element structure under the default root element will cover the token elements produced by the lexer module. Just to make sure it will not be forgotten - the compatibility of the BaseDocument to swing document implementations will also include undoing of position offsets and allowance of getting the extra '\n' at the end of the document (i.e. doc.getText(doc.getLength(), 1) will be valid like it is in the swing document implementations). As a side not: The same problem also exists when one uses the Java Import Tool (JavaKit$FastImportAction) with the external editor. The imported statement is added to the document by one character off. Requesting a waiver for FFJ 4.0 (Orion) -- FFJ40_WAV. Fixing this for external editor would break modules depending on the existing behavior. Mila, please provide more details if you can. The fix for the line elements is simple, it's attached in the http://www.netbeans.org/issues/show_bug.cgi?id=14546 The main problem that remains is the fact that nobody depends on the editor module directly (in order to easily plug other editor to NB) so there could be e.g. old java module working with the new editor (with the bug fixed) which could damage the generated code. However I have talked to java module people again and they will increase the openide version they depend on (due to ErrorManager.getDefault()) etc. which could be a way how to get rid of the problem (declare dependency of the editor module on the same version of the openide and fix both java and editor at the same time). However we need to find out first whether there is any other module (besides java and externaleditor) depending on fixing that problem. BTW I've checked the new document content (char-storage, mark-vector and line-element support) into lexer_based_editor_20020404 branch. This content will replace the current content in NB4.0. I've built tests to verify compatibility with the javax.swing.text document implementations. Unfortunately I can't replace the current content without breaking the compatibility because there is support for some additional functionality like mark moving etc. Waiver approved. *** Issue 14546 has been marked as a duplicate of this issue. *** Is a fix planned for NB 3.4? Or only 4.0 as suggested by the branch discussion below. The editor and java parts of the fix are ready and the fix is planned for 3.4. I'm greping the repository for all the 'findLineRootElement()' 'getEndOffset()' etc. to find out potential problems. I would like to close the bug until the end of this week. Unfortunately there was another problem discovered with getEndPosition(). I'm attaching the current editor diff. Created attachment 6235 [details]
Editor diff
There was one java test failing due to the incorrect last line end offset - which is now fixed. All the java tests now pass. Attaching the editor diff. Created attachment 6252 [details]
Editor diff
Fixed in editor: Checking in libsrc/org/netbeans/editor/BaseDocument.java; /cvs/editor/libsrc/org/netbeans/editor/BaseDocument.java,v <-- BaseDocument.java new revision: 1.87; previous revision: 1.86 done Checking in libsrc/org/netbeans/editor/DocCache.java; /cvs/editor/libsrc/org/netbeans/editor/DocCache.java,v <-- DocCache.java new revision: 1.25; previous revision: 1.24 done Checking in libsrc/org/netbeans/editor/DocOp.java; /cvs/editor/libsrc/org/netbeans/editor/DocOp.java,v <-- DocOp.java new revision: 1.16; previous revision: 1.15 done Java part: Checking in src/org/netbeans/modules/java/JavaParserGlue.java; /cvs/java/src/org/netbeans/modules/java/JavaParserGlue.java,v <-- JavaParserGlue.java new revision: 1.37; previous revision: 1.36 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/java/codegen/CodeGenerator.java; /cvs/java/src/org/netbeans/modules/java/codegen/CodeGenerator.java,v <-- CodeGenerator.java new revision: 1.9; previous revision: 1.8 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/java/imptool/ImpDataSource.java; /cvs/java/src/org/netbeans/modules/java/imptool/ImpDataSource.java,v <-- ImpDataSource.java new revision: 1.16; previous revision: 1.15 done removing relnote keyword as this seems to be resolved for 3.4. If there are any lingering issues that need to be noted, please let me know. Verified in dev 200310100100. |