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.

Bug 17061 - BaseDocument quirk causes New "Main" Template to be corrupted in the external editor
Summary: BaseDocument quirk causes New "Main" Template to be corrupted in the external...
Status: VERIFIED FIXED
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: Sun SunOS
: P2 blocker (vote)
Assignee: issues@editor
URL:
Keywords:
: 14546 (view as bug list)
Depends on:
Blocks: 14546
  Show dependency tree
 
Reported: 2001-10-27 02:22 UTC by Torbjorn Norbye
Modified: 2007-11-05 13:44 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Editor diff (9.47 KB, patch)
2002-06-12 17:16 UTC, Miloslav Metelka
Details | Diff
Editor diff (10.07 KB, patch)
2002-06-13 18:38 UTC, Miloslav Metelka
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Torbjorn Norbye 2001-10-27 02:22:22 UTC
I think I've mentioned this before but it's still there in a fresh
CVS build and I don't think I filed a bug before so here goes:

Start up NetBeans; on the sampledir filesystem, right click, select new =>
Classes => Main.  Next. Give it the name "Foo". Hit Finish.

In the file which comes up, you get this header:

/*
 * Foo.java
 *
 * Created on October 26, 2001, 6:18 PM
 */
**
 *
 * @author  tor
 */

(note: invalid java syntax, and different from what happens in the
builtin editor and what the template itself calls for.)
Comment 1 David Weatherford 2002-03-16 03:31:49 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.


Comment 2 Miloslav Metelka 2002-03-18 10:36:03 UTC
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.
Comment 3 Miloslav Metelka 2002-03-29 16:46:47 UTC
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).
Comment 4 Melih Ovadya 2002-04-10 01:12:47 UTC
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.
Comment 5 Jan Chalupa 2002-04-22 12:28:28 UTC
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.
Comment 6 Miloslav Metelka 2002-04-22 17:11:23 UTC
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.
Comment 7 Miloslav Metelka 2002-04-23 13:03:28 UTC
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.
Comment 8 Jan Chalupa 2002-05-02 10:35:42 UTC
Waiver approved.
Comment 9 Miloslav Metelka 2002-05-09 14:13:55 UTC
*** Issue 14546 has been marked as a duplicate of this issue. ***
Comment 10 Torbjorn Norbye 2002-06-03 19:57:46 UTC
Is a fix planned for NB 3.4? Or only 4.0 as suggested by the
branch discussion below.
Comment 11 Miloslav Metelka 2002-06-04 08:45:10 UTC
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.
Comment 12 Miloslav Metelka 2002-06-12 17:14:17 UTC
Unfortunately there was another problem discovered with
getEndPosition(). I'm attaching the current editor diff.
Comment 13 Miloslav Metelka 2002-06-12 17:16:25 UTC
Created attachment 6235 [details]
Editor diff
Comment 14 Miloslav Metelka 2002-06-13 18:37:31 UTC
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.
Comment 15 Miloslav Metelka 2002-06-13 18:38:22 UTC
Created attachment 6252 [details]
Editor diff
Comment 16 Miloslav Metelka 2002-06-17 17:39:28 UTC
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
Comment 17 Patrick Keegan 2002-07-23 16:00:22 UTC
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.
Comment 18 pfelenda 2003-10-14 11:34:34 UTC
Verified in dev 200310100100.