The unit tests are in both xamui and schema/core. Just open QuietUndoManager and
uncomment the last redo() line in the testIssue83963() method.

Note that:

1. The document edit must start on the last line of the model edit change.

2. The document edit must be non-trivial.

The document text is intact, it is the FixLineSyntaxState class in NetBeans that
is causing a BadLocationException and throwing up. I need a debug build of
NetBeans to see what is going on, but my one attempt at building from source
failed because the file layout changed, according to the "golden" file. 

I did the above scenario, except I used "newComplexType" instead of "borrow".
These are the findings.

1. After doing 2 Redo's as mentioned in the scenario. I see XDM/Schema/AXI model
all valid. However in the source view, the text before </xsd:schema> looks wierd.
See attachment issue83963.png.

2. Eventhough the source looks wierd, I can add complextypes. As I make changes
to the "newComplexType", like add a new element, then the source gets updated.
See attachment issue83963_2.png. 

Created attachment 33788 [details]
source view

Created attachment 33789 [details]
source view updated

After debugging further by adding a document listener to document and printing
the offsets and length of insert/remove, final document length after each
undo/redo operation. I do not see any issue in XDM/XAM/Schema/AXI codes. This
looks like a NB55 Editor issue in FixLineSyntaxState.java code.

See attachment that contains the Source view, with contents twisted, and the
line number 8 duplicated. Lines 9-15 are missing. But document contents seems to
be correct.(using  Ctl+A, Ctl+C)

Created attachment 33803 [details]
twisted contents in source view

Assigning to xml/text-editor team, since all the debugging informatin suggests
FixLineSyntaxState.java.

> With trunk build 060831_1, jdk1.5.0_07...

Did you really mean trunk? These features are not a part of trunk codebase, only
in NetBeans 5.5.

It looks like either a bad usage of the undo/redo or a bug in
FixLineSyntaxState. I do not see any dependency of the problem on xml editor.
Reassigning to editor - Mila Metelka.

Please apply the attached patch and re-run the test so that we see where the
exception really occurred. Thanks.

Created attachment 33872 [details]
Patch for better exception diagnostics

Created attachment 33873 [details]
Patch for better exception diagnostics

IIRC there were no similar problems experienced with FixLineSyntaxState recently
so I suppose this occurred after you've started to use your special undo manager
(removal of the checking for last event to be undone in the BaseDocument by
issue #83740 allowed you to do that).

 I have read again the http://xml.netbeans.org/specs/undo/ and I'm still not
sure that I understand your undo manager solution. However please keep in mind
that regarding the document undos/redos you must always apply them in the proper
order, you cannot skip any of them or insert extra edits between them. Otherwise
the things would get seriously broken because the edits use absolute offsets of
where the changes are performed so the edits would be applied at wrong places in
the document.

If I could suggest you a solution regarding special undo manager then please
override

    protected UndoRedo.Manager createUndoRedoManager() {
        return new CESUndoRedoManager(this);
    }

and make your own UndoRedo.Manager that will mostly delegate to the UM obtained
from super.createUndoRedoManager() except the undoableEditHappened() method.
That method will normally obtain the undoable edit performed in the document. At
that time you should already know the changes in your visual editor and have
them ready as an undoable edit (your undo manager should be able to access them).
The undoableEditHappened() method should then be implemented in the following way.

    public void undoableEditHappened(final UndoableEditEvent ue) {
        if (visualEdit != null) { // any visual changes performed?
            UndoableEdit origEdit = ue.getEdit();
            WrapperCompoundEdit wrapperEdit = new WrapperCompoundEdit(origEdit,
visualEdit);
            ue = new UndoableEditEvent(ue.getSource(), wrapperEdit);
        }
        delegateCESUndoManager.undoableEditHappened(ue);
    }

Regarding the fact that you can have multiple document edits for a single change
- if you execute your changes wrapped by NbDocument.runAtomic() then all your
document changes within that transaction will appear as a single undoable edit.

Or if you want to merge multiple visual changes into just one undo edit you may
use UndoableEdit.replaceEdit() mechanism for merging.

The issue to which you are referring (issue 83740) was fixed a week after this
bug was entered, so no, that had nothing to do with this problem.

Our undo manager is, in fact, delegating to the CloneableEditorSupport undo
manager, and we are keeping the undoable edits in the order in which they
arrive, and we are not introducing any edits that modify the document. This is
all explained in the undo spec to which you referred.

Regarding your other questions/comments, I believe the undo spec should explain
everything. The schema model is generating undoable edits of its own, and our
undo manager is collecting those (and passing them to CESUndoRedoManager).
Likewise, the undo manager is collecting the document edits coming from the
source editor. The only thing our undo manager does is undo/redo several edits
at once, depending on the state of the undo manager.

You can see the code for yourself in release55 branch, in xml/xamui/src/.../undo
(CompoundUndoManager and QuietUndoManager classes).

By the way, using the attached patch, I was only able to get the following extra
information from the exception stack trace:

Caused by: javax.swing.text.BadLocationException: Length must be positive
        at javax.swing.text.AbstractDocument.getText(AbstractDocument.java:815)
        at
org.netbeans.editor.FixLineSyntaxState.fixSyntaxStateInfos(FixLineSyntaxState.java:348)
        ... 50 more

That did not seem to help very much, as we already knew where the exception was
occurring by using the debugger and stepping through the code.

I have debugged the problem with the following scenario similar to yours:
1) Have empty xsd
2) In Schema view Add Complex Type name it "a"
3) In Source view I type Enter then "<xsd"; choose "<xsd:simpleType" from code
completion; type " name="b">"; choose "</xsd:simpleType>" from completion (I'm
describing it in a detail because in slightly different case the exception was
not thrown but this one always worked). So I end up with

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            targetNamespace="http://xml.netbeans.org/schema/xmlSchema"
            xmlns:tns="http://xml.netbeans.org/schema/xmlSchema"
            elementFormDefault="qualified">
    <xsd:complexType name="a">
        <xsd:sequence/>
    </xsd:complexType>
    <xsd:simpleType name="b"></xsd:simpleType>
</xsd:schema>

4) In schema I do Undo; Undo; Redo and the following Redo will throw an exception.

I have patched the class BaseDocumentEvent in editor library to show the
creation of the document modification events and their undo and redo. I have
added a static counter to verify the proper order of the events in undo/redo.
The order was correct but there is another problem - there are document
modifications (document.insertString()/remove()) performed and followed by redo
of edits that were done *before* the just performed modifications. That cannot work.
In fact I don't understand why the undo/redo should do any extra modifications.

Regarding the attached log - at the end of the second undo the document
modifications are performed:
UNDO of id=66
    UNDO of id=66 finished
UNDO of id=65
    UNDO of id=65 finished
UNDO of id=64
    UNDO of id=63 after this undo ...
UNDO of id=63
    UNDO of id=63 finished
    UNDO of id=64 finished
CREATED id=82, type=REMOVE, offset=277, length=77
    removed text='    <xsd:complexType name="a">
        <xsd:sequence/>
    </xsd:complexType>'
CREATED id=83, type=INSERT, offset=277, length=17


The first redo:
CREATED id=84, type=REMOVE, offset=277, length=17
    removed text='
                '
CREATED id=85, type=INSERT, offset=277, length=77


The second redo:
REDO of id=64
    REDO of id=63 before this redo ...
REDO of id=63
    REDO of id=63 finished
    REDO of id=64 finished
REDO of id=65
    REDO of id=65 finished
REDO of id=66
    REDO of id=66 finished
REDO of id=67
    REDO of id=67 finished
REDO of id=68
    REDO of id=68 finished
REDO of id=69
*********** Exception occurred ************ at 2:32 PM on Sep 15, 2006
java.lang.IllegalStateException: javax.swing.text.BadLocationException: Length
must be positive
        at
org.netbeans.editor.FixLineSyntaxState.fixSyntaxStateInfos(FixLineSyntaxState.java:492)
        at
org.netbeans.editor.FixLineSyntaxState.update(FixLineSyntaxState.java:275)
...

Created attachment 34005 [details]
Extra debugging for BaseDocumentEvent in release55 branch

Created attachment 34006 [details]
Log with the extra debug information from the described reproduction case

Marking invalid for the editor (please reopen and reassign if you want to
continue to solve the problem on your side in terms of this issue).

Created attachment 34030 [details]
Stacktraces of the problematic modifications; the IDE run with -J-Dnetbeans.debug.editor.document.stack=true

We are trying a workaround in xdm module that will avoid the exception in editor
code.

checked into release55_dev.

Source changes (XDM module)
http://xml.netbeans.org/source/browse/xml/xdm/src/org/netbeans/modules/xml/xdm/XDMModel.java?r1=1.2.2.45&r2=1.2.2.45.2.1

Testcase: (Schema module testcase for above fix)
http://xml.netbeans.org/source/browse/xml/schema/api/test/unit/src/org/netbeans/modules/xml/schema/model/impl/xdm/Attic/UndoRedoTest.java?r1=1.1&r2=1.1.2.1
http://xml.netbeans.org/source/browse/xml/schema/api/test/unit/src/org/netbeans/modules/xml/schema/model/resources/Attic/undoredo.xsd?r1=1.1&r2=1.1.2.1

Assigning to myself, since we have a solution that will avoid the Exception.

Reviewer comments:

Hi Ayub the change looks safe to me.
-Nam 

QE comments:

using trunk build 060915, with xdm.xml & xdm.jar replaced
per Ayub's instructions: issue is fixed... no more NPE and
undo/redo work fine in this scenario.

thanks,
hao.

Files changed:

/cvs/xml/schema/api/test/unit/src/org/netbeans/modules/xml/schema/model/impl/xdm/Attic/UndoRedoTest.java
new revision: 1.1.4.1; previous revision: 1.1

/cvs/xml/xdm/src/org/netbeans/modules/xml/xdm/XDMModel.java
new revision: 1.2.2.46; previous revision: 1.2.2.45

/cvs/xml/schema/api/test/unit/src/org/netbeans/modules/xml/schema/model/resources/Attic/undoredo.xsd
new revision: 1.1.4.1; previous revision: 1.1

Verified in CB 060920_11.