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.
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...
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.