Bug 150251

Reproducible in a dev build. First undo removes the '(', second removes the 'append' and adds '(' and the third undo
adds 'print'. The removal and insertion of '(' looks really strange.

Mila - do you still plan to create a support for grouping of undoable edits?

Fixed in jet-main.

http://hg.netbeans.org/jet-main/rev/1ca1facd3eea

Integrated into 'main-golden', will be available in build *201101090000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/1ca1facd3eea
User: Dusan Balek <dbalek@netbeans.org>
Log: Issue #150251: Too high granularity of undo history when undoing CC (Ctrl+Enter) - fixed.

The fix from comment 3 creates an undo granularity problem when the code completion occurs in a nested situation (which happens with code completion in jVi input mode). In particular, in jVi every user keystroke must be undone separately. See below in "before undo-manager patch" for an example.

The issue arises because of either of two things
1) The fix does a begin/end commit group for each character.
   This is because item.processKeyEvent may mutate the document;
   in particular when java.completion sees Ctrl-Enter, 
   it changes the document in anticipation of the infrastructure 
   completing the change.
2) An empty begin/end commit group, one with no changes in it,
   forces separate commit groups.

About (1), there is no way for the completion provider to inform the completion API that it intends to modify the document; this makes centralized undo granularity handling in the impl code trickier. This might be considered a deficiency in the API. Note that each keystroke typically does 3 begin/end commit-group; one pair for each of KEY_PRESSED, KEY_TYPED and KEY_RELEASED.

The problem can be fixed by addressing (2). I've filed bug 199568 with a patch to the UndoGroupManager which has the UndoManager ignore the empty begin/end pairs. See below for the change in jVi undo behavior.

Here are examples of doing Ctrl-Z after code completion. Two cases are shown:
- using the Ctrl-Enter feature to overwrite (this bug is about that)
        System.err.append("");
- the typical case (which the fix for this bug messes up in jVi)
        "".codePointBefore(0);

The second test sequence is generated by, starting with:
        ""|
type the characters:
        .cod<TAB>b<ENTER>0<ENTER>
which results in
        "".codePointBefore(0);|
then enter a bunch of Ctrl-Z/undo

=== before undo-manager patch
    NB
        System.err.append("");
        System.err.println("");

        "".codePointBefore(0);
        "".codePointBefore(index);
        "".codePointb
        "".codePoint
        "".cod
        "".
        ""
    jVi
        System.err.append("");
        System.err.println("");

        "".codePointBefore(0);
        "".codePointBefore(index);
        "".codePointb
        "".codePoint
        "".cod
        "".co                           <<< extra stuff in jVi
        "".c
        "".
        ""

=== after undo-manager patch
    NB (same as before undo-redo patch)

    jVi
        System.err.append("");
        System.err.println("");

        "".codePointBefore(0);
        "".codePointBefore(index);
        "".codePointb
        ""

BTW, before the fix from comment 3, jVi undo behavior was
        "".codePointBefore(0);
        ""
so for jVi it's a regression.

The behavior after the fix and undoMgr patch, could be considered a feature. I'm thinking about offering a patch that would allow setting a system property to tweak the undo granularity. More about that later...

Since the proposed patch has been already integrated, considering this issue as fixed.