Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 150251 - Too high granularity of undo history when undoing CC (Ctrl+Enter)
Too high granularity of undo history when undoing CC (Ctrl+Enter)
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: Completion & Templates
6.x
All All
: P3 (vote)
: 7.1
Assigned To: Miloslav Metelka
issues@editor
:
Depends on: 199568
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-15 16:09 UTC by Petr Dvorak
Modified: 2013-08-21 13:55 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Dvorak 2008-10-15 16:09:22 UTC
Product Version: NetBeans IDE Dev (Build 200810150201)
Java: 1.6.0_07-rev; Java HotSpot(TM) Client VM 10.0-b24
System: Linux version 2.6.24-19-generic running on i386; UTF-8; en_US (nb)

Have a following  line:

System.out.|print("Hello"); // '|' stands for caret...

Press Ctrl+Space to invoke code completion and choose for example "append" in the list and press Ctrl+Enter (use
suggestion + overwrite).

Try to undo the change - you need to press Ctrl+Z three times, in spite of the fact that the replace operation feels
like an atomic operation...
Comment 1 Vitezslav Stejskal 2008-10-16 11:20:06 UTC
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.
Comment 2 Dusan Balek 2008-11-24 12:22:28 UTC
Mila - do you still plan to create a support for grouping of undoable edits?
Comment 3 Dusan Balek 2011-01-06 13:32:34 UTC
Fixed in jet-main.

http://hg.netbeans.org/jet-main/rev/1ca1facd3eea
Comment 4 Quality Engineering 2011-01-09 06:16:56 UTC
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.
Comment 5 err 2011-06-21 06:01:21 UTC
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
        ""
Comment 6 err 2011-06-21 06:54:41 UTC
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...
Comment 7 Dusan Balek 2013-08-21 13:55:16 UTC
Since the proposed patch has been already integrated, considering this issue as fixed.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo