Yes, this is the problem. I need to fix it.
The same problem exists also in XML tools stuff ( Schema editor f.e. ).

The problem is it seems in calling just notifyUnmodified() method.
But one needs to call one more method: setAlreadyModified().
Either method callNotifyUnmodified() should be used instead of notifyUnmodified().
But both methods have package local access and they cannot be called outside of
impl of CloneableEditorSupport impl.

I have contacted with Jaroslav Tulach about this problem.

I guess your code must be doing something strange, as Ctrl-Z correctly marks 
the state of document on plain CloneableEditorSupport, maybe that you somehow 
mess the UndoableEdits in the UndoRedo.Manager.

It would probably help if the problem could be isolated into a simple test 
case, for example one similar to:
http://www.netbeans.org/source/browse/openide/text/test/unit/src/org/openide/text/UndoRedoCooperationTest.java?rev=1.4&view=markup

It seems to me that directly calling notifyUnmodified is not good idea, the 
method is there to allow the CloneableEditorSupport to notify subclasses that 
something changed, it is not made to be called directly. The other methods you 
mentioned like callNotifyUnmodified() are not intended to be called from 
external code either, and that is the reason they are private.

I guess it is necessary to find out what is wrong with the UndoableEdits.

Jaroslav,

we have some undo framework that is not related to undo in CloneableEditorSupport.
I mean we have some view that can perform undo. But it is not call undo in 
CloneableEditorSupport. This is the problem.
Our undo replace document content itself without knowing about
CloneableEditorSupport.
>It seems to me that directly calling notifyUnmodified is not good idea
May be you are right here but we need some way to mark or unmark document as 
modified. This is the problem.

Here summary of problem:
So we have some undo manager that perform undo itself without calling undo in
CloneableEditorSupport. We need somehow unmark document as modified generaicaly 
from this undo manager without invoking undo in CloneableEditorSupport. 
Current method notifyUnmodified() works badly. And possibly should not called
at all. So what is the way for doing what we need ? 

It is not easy to advice something, without really knowing your code, but 
consider whether following solution could be applied to your case:

I guess you have your component that returns your own UndoRedo. I think that 
your UndoRedo should be superset of the CloneableEditorSupport UndoRedo. There 
are two ways to do it, either add your own UndoableEdits to existing 
CloneableEditorSupport UndoRedo, or have your own UndoRedo and listen on 
CloneableEditorSupport's one and reuse its UndoableEdits.

As a result any change you made to the document will be properly recorded into 
the UndoRedo. Plus all the UndoableEdits you think are important shall be 
added there as well. This will create a sequence of all operations that, if 
undone, will return the Document as well as your data structures to original 
state.

Of course you may not want the whole sequence, you would like to group certain 
set of operations into one. For example when you drag'n'drop an element in 
BPEL and this then regenerates code in editor on 10 places, you want this to 
be just one UndoableEdit. This shall be supported by UndoableEdit.addEdit 
method. Just insert your own CompoundEdit into the UndoRedo and make it 
consume any other edit that comes after it. Do the changes to the document, 
all of them get consumed by the initial edit, and at the end, "close" to 
compound edit, e.g. tell it to not consume any other event anymore. If you 
then undo the compound edit, everything shall return back to the original 
state.

>It is not easy to advice something, without really knowing your code
Yes, I think so.

You can see code in 
http://enterprise.netbeans.org/source/browse/enterprise/bpel/core/src/org/netbeans/modules/bpel/core/Attic/BPELDataEditorSupport.java?only_with_tag=release55
( UndoRedo manager )
and here 
http://enterprise.netbeans.org/source/browse/enterprise/bpel/bpelapi/src/org/netbeans/modules/bpel/model/impl/Attic/BpelModelImpl.java?only_with_tag=release55
undo/redo actions realization.

Unfortunately my knowing of this area is very very little. I need time to think
about your suggestion. This is stuff in DataObject was not mine originally
and I try to learn it from Schema DataObject that has related code.
Today is my last day before vacation and I don't have a time to think about
it more.
I have sent the letter also to authors original code in Schema dataobject
about this issue. I beleive they have the same problem ( at least I have saw
this issue some time ago. )
Thank you for your help, I will try to solve this problem after vacation.

Hi Yarda,

I am largely responsible for the strange undo/redo solution we have in the XML
Schema editor. For a brief introduction to the problem, please have a look at
the undo/redo specification: http://xml.netbeans.org/specs/undo/

See also issue 81023 which I entered, and asks for the same thing as Denis (make
the methods we need to use protected). Further background can be seen in issue
77333, issue 80754, and issue 81028.

In short, we have two different editor views (in a multiview). One of them is
the XML text editor, which is based on CloneableEditor and
CloneableEditorSupport. The other is a generic TopComponent with a graphical
interface for modifying the underlying XML schema model, and an undo/redo
manager of its own. The changes are made two different ways:

1. The user edits the source. Changes are eventually flushed to the model, in
which case the model reparses the text and rebuilds the entire structure. This
is not at all efficient, so as a general solution to undo/redo, this is to be
avoided.

2. Via the graphical interface, the user can modify the schema model directly.
Changes to the model are synced to the text as well. Because the model is
writing to the Document instance, undoable edits are fired and they are
collected on the CES undo/redo manager. Meanwhile, undoable edits are fired from
the schema model, and they are collected in our own custom undo/redo manager.

Our simplistic solution is described in the specification mentioned above. Given
this is a bit complicated, and I don't yet understand your solution, I will have
to look more deeply at this in a few days.

Thanks

According to the spec, I can see, that you have already tried few different 
implementations. I feel a bit bad for pushing you back to single manager, 
however I believe it should work. As a sample code is more than thousands 
words, I wrote a sample testcase:
http://openide.netbeans.org/source/browse/openide/text/test/unit/src/org/openide/text/UndoRedoWrappingExampleTest.java?rev=1.1&content-type=text/vnd.viewcvs-markup
it seems to work, except the fact that I had to also fix one line in 
CloneableEditorSupport:
http://openide.netbeans.org/source/browse/openide/text/src/org/openide/text/CloneableEditorSupport.java?r1=1.20&r2=1.21
which is not good news if you want to build on top of 5.5.

Can the fix be in 5.5 FCS?

platform cluster for 5.5 is supposed to be fully compatible with 5.0 for 
external observers. This fix is not that compatible, as clearly one can write 
an external code and see the difference.

On the other hand I am interested in helping to fix "mixed model" undo issues. 
So I am ready to find a way how to get this fix or something similar to 5.5. I 
just need to know that it pays off.

That is why I'd like you to try to rewrite your undo in the style shown at
http://openide.netbeans.org/source/browse/openide/text/test/unit/src/org/openide/text/UndoRedoWrappingExampleTest.java?rev=1.1&content-type=text/vnd.viewcvs-markup
and if that works for you, let then consider including the fix
http://openide.netbeans.org/source/browse/openide/text/src/org/openide/text/CloneableEditorSupport.java?r1=1.20&r2=1.21

I am sorry for being so careful, but the fact that I wrote the test does not 
mean everything in your code will work. Also nobody says that the found bug is 
the only one that will be encountered in this area. 

So I guess the ball is on your side. Try to find someone to rewrite the code, 
let me know where it is, if it works. If there are problems, please contribute 
them as test cases to 
http://openide.netbeans.org/source/browse/openide/text/test/unit/src/org/openide/text/UndoRedoWrappingExampleTest.java?rev=1.1&content-type=text/vnd.viewcvs-markup
so I can fix them easily. 

I have fixed issue 80754 and issue 81028 by redesigning the undo/redo support in
the schema editor. This redesign is documented at the following URL:
http://xml.netbeans.org/specs/undo/ (thanks to Yarda for pointing me in the
right direction).

In short, the undo/redo support is now accessible to all of the editors that
operate on XAM-based models. After tomorrow, it will in fact have nothing to do
with XAM at all, and is simply a solution to the common problems of managing
undoable edits coming from multiple sources, and managing an undo queue that is
accessible from multiple views.

Please have a look at the updated spec. You can see example usages of the
undo/redo support in the schema/core module on the release55 branch
(SchemaEditorSupport and the column and source multiview elements contain the
relevant code).

I believe this issue can be fixed by following the schema editor example. If you
have any questions, please write to me and I'll be happy to help.

I am glad to hear that you have managed to solve your problem. I am sure you 
are not the only one who has to fight with implementation of complex Undo/Redo 
functionality. Maybe we could turn http://xml.netbeans.org/specs/undo/ into a 
tutorial!? What do you think Geertjan?

This is fixed, but some issues with undo/redo are remaining.
Will fix them later. They don't have relation to this issue.

Verified in build from 06.08.25