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.
On Editor, when try to continue UNDO (Ctrl-Z) to delete Japanese characters, some intermediate character is shown in the editor. How to reproduce: 1) Open a New text file in the editor 2) Switch to KANJI mode 3) Type k a k a k a and Enter Now you see KA KA KA (3 Japanese texts) 4) Hit Ctrl-Z (UNDO) then you will see the inputed characters are deleted in a strange way.. 0. KAKAKA (before Ctrl-Z) 1. (1st hit of Ctrl-Z .. nothing on the line) 2. KAKAKA (2nd hit) 3. (3rd ..) 4. KAKAk (4th hit .. here a fragment `k` is shown ) 5. 6. KAKA 7. 8. KAk 9. 10. KA 11. 12. k 13. For your information, Backspace key and Delete key can delete Japanese text one by one.
Priority is changed to P4 (normal).
Only changed version to Development.
Version: 'Dev' -> 3.2
Target milestone -> 3.3
*** Issue 10676 has been marked as a duplicate of this issue. ***
Target milestone -> 3.3.1.
*** Issue 19313 has been marked as a duplicate of this issue. ***
making P3 since user in Japanese locale should be able to operate in editor the same as user in English or European locales. ken.frank@sun.com 03/08/2002
I was not able to reproduce it in the newest builds. What is happening to me is that after I enter kakaka and enter the Ctrl-Z removes whole word. I think this is correct way to deal with it no? Could any one of you try to reproduce it in the latest build and write feedback here? I would recommend to close this issue as 'worksforme'. What is your oppinion, Mila?
Honzo F., could you ask Japanese guys to check if it works or not?
I have verified it and asked Japanese people for checking and here is the result: Please hit Ctrl-Z again and again. Input Japanese "KAKAKA" Hit Ctrl-Z Hit Ctrl-Z Hit Ctrl-Z.... When first hitting, Japanese "KAKAKA" is erased. (correct behavior). When second and third hitting, Japanese "KAKAKA" comes back, and it's corrupted, what is not correct. Thus the fix failed.
Set target milestone to TBD
I think the problem is caused by the fact that when creating the japanese word using input method all intermediate results are stored as undoable edits. After that the last (correct) edit is stored aswell, but the undo queue is already full of those bad edits so when hitting UNDO more then once... So the fix is to disable firing undoable edit events during japanese word composition. Diff of proposed fix below.
Created attachment 8525 [details] diff in -c format
Integrated into main trunk: Checking in libsrc/org/netbeans/editor/BaseDocument.java; /cvs/editor/libsrc/org/netbeans/editor/BaseDocument.java,v <-- BaseDocument.java new revision: 1.89; previous revision: 1.88 done
Verified this bug on build: NetBeans dev build ------------------ Number: 200302130100 Branch: trunk Checked it using JDK 1.4 and worked fine on Windows 2000 with Japanese environment.
Verified on Sierra RC5_a Build with the patches. OS:win2000 jdk:1.4.0_02
Resolved for 3.4.x or earlier, no new info since then -> closing.
could not verify fix on sierra update1 with patch 113638-4. Configuration: Build:Sierra Update1 020923 JDK:1.4.0_03 Locale:ja_JP
I just tried this fix as well and it did not work. It was ok if I only did UNDO and REDO once the composed text was accepted (via Enter), but if I did it while composing the text I would soon start getting exceptions. It seems that the length of the document would get out of whack.
This is an example of the JavaExceptions that I see (see note above). This is from NetBeans 3.5.1. javax.swing.undo.CannotUndoException at org.netbeans.editor.BaseDocumentEvent.undo (BaseDocumentEvent.java:211) at org.netbeans.editor.GuardedDocumentEvent.undo (GuardedDocumentEvent.java:41) at javax.swing.undo.CompoundEdit.undo(CompoundEdit.java:46) at org.netbeans.editor.BaseDocument$AtomicCompoundEdit.undo (BaseDocument.java:1302) at javax.swing.undo.UndoManager.undoTo(UndoManager.java:210) at javax.swing.undo.UndoManager.undo(UndoManager.java:275) at org.openide.actions.UndoAction.performAction (UndoAction.java:120) at org.openide.util.actions.CallableSystemAction.actionPerformed (CallableSystemAction.java:69) at org.netbeans.modules.editor.NbEditorKit$NbUndoAction.actionPerformed (NbEditorKit.java:332) at org.netbeans.editor.BaseAction.actionPerformed (BaseAction.java:137) at javax.swing.SwingUtilities.notifyAction (SwingUtilities.java:1530) at javax.swing.JComponent.processKeyBinding (JComponent.java:2438) at javax.swing.JComponent.processKeyBindings (JComponent.java:2473) at javax.swing.JComponent.processKeyEvent (JComponent.java:2401) at java.awt.Component.processEvent(Component.java:4909) at java.awt.Container.processEvent(Container.java:1569) at java.awt.Component.dispatchEventImpl(Component.java:3615) at java.awt.Container.dispatchEventImpl(Container.java:1627) at java.awt.Component.dispatchEvent(Component.java:3477) at java.awt.KeyboardFocusManager.redispatchEvent (KeyboardFocusManager.java:1713) at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent (DefaultKeyboardFocusManager.java:627) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent (DefaultKeyboardFocusManager.java:831) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions (DefaultKeyboardFocusManager.java:741) at java.awt.DefaultKeyboardFocusManager.dispatchEvent (DefaultKeyboardFocusManager.java:592) at java.awt.Component.dispatchEventImpl(Component.java:3506) at java.awt.Container.dispatchEventImpl(Container.java:1627) at java.awt.Window.dispatchEventImpl(Window.java:1606) at java.awt.Component.dispatchEvent(Component.java:3477) [catch] at java.awt.EventQueue.dispatchEvent(EventQueue.java:456) at java.awt.EventDispatchThread.pumpOneEventForHierarchy (EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForHierarchy (EventDispatchThread.java:151) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:145) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:137) at java.awt.EventDispatchThread.run (EventDispatchThread.java:100)
It seems that there is some problem related to skipping of the document events for the text composing. We need to check whether isLastModifyUndoEdit() in canUndo() works OK in this situation. I hope that we will be able to fix this into 3.6.
I've checked again on Solaris with Japanese with current builds on jdk1.4.2_05 and it works fine. I've tried both undo and redo both when I was in the middle of the input method or when I've finished it. I guess the previous problems could be caused by the asynchronous implementation of UndoRedo which is now synchronous again (please see issue 42005 for details). Therefore closing as fixed. Please reopen if the problems persist.
Could someone who faced the problems verify this issue? Thanks.
Verified.