When using Vi input mode and you have a keyboard layout with dead keys, it's not possible to jump to a mark. When you type ', then space and then the mark's letter the editor writes a ' to the buffer instead of doing the jump. For instance, typing ', space, a writes ' to the buffer (even though the current mode is visual mode, not insert mode). If I change the keyboard layout to one without dead keys, I can jump to marks. In Vim, this works. You can type ', space, letter and the cursor will jump to the mark. Reproducible: Always Steps to Reproduce: 1. Open text file. 2. Go to a line and type ma to set mark a. 3. Go to another line and type ', space, a Actual Results: The editor adds ' to the buffer. Expected Results: Jump to the mark.
I'm currently on KDE 4.12.3. This has never worked, though.
Hi Thiago. Thanks for reporting this, but I can't reproduce it. Your example doesn't work on vim either :/ Your mark is named a, therefore the way to access it is "ma". If you type "m ", the mark is expected to be space, and it doesn't exist, so it doesn't jump anywhere. Moreover, in vim marks *have* to be a letter ([a-zA-Z]). Could you provide more information on this ? :)
In my previous comment I meant "'a" instead of "ma" and "' " instead of "m ". Typos ... :P
Hello Miquel, Thanks for looking into this. I just created a new user and tried with that one in order to get a stock KDE session. I still can reproduce it. Even in Vim and GVim. Which keyboard layout are you using? The keyboard layout I'm using is "English (US), variant English (US, interntional with dead keys)", but it also happens with other layouts which use dead keys, such as "Portuguese (Brazil), default variant." I set these by going to System Settings → Input devices → Keyboard → Layouts → Add. The marks I use and that I mention in this report are letters. You can reproduce it with a mark you set with "ma". I never tried to add or jump to a mark called space. The only way to type 'a (that is, apostrophe immediately followed by a) in a keyboard layout with dead keys is to press the following sequence of keys in your keyboard: apostrophe, space bar, a. There is no other way to get an apostrophe. When you first press the apostrophe key, the apostrophe character will not be sent to the application. Instead, the system will wait to see which key you type next. If it is a letter, you get an accented character like "á" for instance. If it is the space bar, then the apostrophe character will be sent to the application. Even though you pressed two keys, the application will get just one character: either an accented letter or the apostrophe. In KWrite or Kate, if you press the keys apostrophe followed by a then as per above KWrite will get the character "á". The strange thing is that even though it is in normal mode it will insert "á" into the buffer. Vim and GVim don't do that, they just ignore the character. The way dead keys work, in normal circumstances, KWrite or Vim or another application will never see the apostrophe character unless the user presses the space bar right after it, because it is a dead key. I'm not sure which layer of the system does the dead key handling, but I believe it's the toolkit, in this case Qt. xev reports the following X events when the user presses the keys apostrophe followed by a: KeyPress event, serial 40, synthetic NO, window 0xaa00001, root 0xa1, subw 0x0, time 9249223, (-1246,244), root:(137,267), state 0x10, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 40, synthetic NO, window 0xaa00001, root 0xa1, subw 0x0, time 9249326, (-1246,244), root:(137,267), state 0x10, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0xaa00001, root 0xa1, subw 0x0, time 9249361, (-1246,244), root:(137,267), state 0x10, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XmbLookupString gives 1 bytes: (61) "a" XFilterEvent returns: True KeyPress event, serial 40, synthetic NO, window 0xaa00001, root 0xa1, subw 0x0, time 9249361, (-1246,244), root:(137,267), state 0x10, keycode 0 (keysym 0xe1, aacute), same_screen YES, XKeysymToKeycode returns keycode: 38 XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a1) "á" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0xaa00001, root 0xa1, subw 0x0, time 9249424, (-1246,244), root:(137,267), state 0x10, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False And the following events when pressing apostrophe, space bar, a: KeyPress event, serial 40, synthetic NO, window 0xaa00001, [19/1443] root 0xa1, subw 0x0, time 9324502, (-402,590), root:(981,613), state 0x10, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 40, synthetic NO, window 0xaa00001, root 0xa1, subw 0x0, time 9324605, (-402,590), root:(981,613), state 0x10, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0xaa00001, root 0xa1, subw 0x0, time 9324963, (-402,590), root:(981,613), state 0x10, keycode 65 (keysym 0x20, space), same_screen YES, XLookupString gives 1 bytes: (20) " " XmbLookupString gives 1 bytes: (20) " " XFilterEvent returns: True KeyPress event, serial 40, synthetic NO, window 0xaa00001, root 0xa1, subw 0x0, time 9324963, (-402,590), root:(981,613), state 0x10, keycode 0 (keysym 0x27, apostrophe), same_screen YES, XKeysymToKeycode returns keycode: 48 XLookupString gives 0 bytes: XmbLookupString gives 1 bytes: (27) "'" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0xaa00001, root 0xa1, subw 0x0, time 9325082, (-402,590), root:(981,613), state 0x10, keycode 65 (keysym 0x20, space), same_screen YES, XLookupString gives 1 bytes: (20) " " XFilterEvent returns: False KeyPress event, serial 40, synthetic NO, window 0xaa00001, root 0xa1, subw 0x0, time 9325986, (-402,590), root:(981,613), state 0x10, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XmbLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0xaa00001, root 0xa1, subw 0x0, time 9326064, (-402,590), root:(981,613), state 0x10, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False I'm surprised to see that the application does see the dead_acute and the a key presses before being sent á. I assume in normal conditions Qt will ignore these events and just use á. Does Katepart do its own X keyboard events processing or does it rely on Qt for that?
Come to think of it, the dead keys handling seems to be done by a combination of X and the toolkit. Judging from the events above, X will combine the dead key and the following key to generate a resulting character, but it will also send the original key presses to the toolkit/application. The toolkit/application will then have to decide what to do with all those events (original key presses plus the combined character generated by X).
Ok, I've tested it now in with US layout (with dead keys) and I can reproduce this bug. I'll take a look at this as soon as possible. Thanks for reporting !
I am wondering if this is related to https://bugs.kde.org/show_bug.cgi?id=396376 The behaviour described in that bug report can be reproduced in kile: Keyboard layout: Czech (QWERTY, extended backslash) Running kate with vi input mode press : to open the command line AltGr+5, which normally produces a % sign, does not have any effect
possible duplicate: https://bugs.kde.org/show_bug.cgi?id=357062
Dead key doesn't work in GVim. Thanks Keyboard: French (AZERT)
*** This bug has been marked as a duplicate of bug 357062 ***