Ctrl+K is overridden by "paste" on dvorak keyboard layout

[stan-janssen]

When I use the standard ctrl+K (for cut line) in bash or nano, this is overridden by the "paste" command, but only if something is on the clipboard. This does not happen in other terminal emulators like Konsole. I suspect that this is because the K on my dvorak keyboard is on the place of the V of a QWERTY keyboard.

This part of the source code (commited in https://github.com/elementary/terminal/commit/f15ba42234651d0efcf12c912a62b9f7140c23a9) in MainWindow.vala looks suspect to me (line 488 and on):

                /* Use hardware keycodes so the key used
                 * is unaffected by internationalized layout */
                if (((e.state & Gdk.ModifierType.CONTROL_MASK) != 0) &&
                                            settings.natural_copy_paste) {
                    uint keycode = e.hardware_keycode;
                    if (match_keycode (Gdk.Key.c, keycode)) {
                        if (current_terminal.get_has_selection ()) {
                            current_terminal.copy_clipboard ();
                            return true;
                        } else { /* Ctrl-c: Command cancelled */
                            current_terminal.last_key_was_return = true;
                        }
                    } else if (match_keycode (Gdk.Key.v, keycode)) {
                        return handle_paste_event ();
                    }
                }

Commenting out this entire section solves the problem for me.

What is the reason that we are using "Hardware keycodes so the key used is unaffected by internationalized layout"?

[jeremypw]

This sounds similar to the issue in Files that was addressed by https://github.com/elementary/files/pull/360. I think the reason for hardware keycodes was so that e.g. Russian keyboards which do not have the relevant letters worked as their users expect.

[stan-janssen]

Is it true that on a Russian keyboard it is customary to use the same physical keys as 'c' and 'v' on a QWERTY keyboard for copy and paste, regardless of which letters might be more appropriate?

On a Dvorak keyboard, one uses the actual 'c' and 'v' keys (which are on the right of the keyboard on a Dvorak layout) for copy and paste.

If this is the case, elementary OS might need some sort of lookup system to see for which layouts the physical keys should be used, and for which layouts the letters on the keys should determine the effect of shortcuts. Or, more generally, if we want to capture the "standard" letters for certain shortcut actions (in this case copy and paste), there should be some library where we can look this up.

[jeremypw]

What the PR indicated above is to check first for the ASCII letters 'X', 'C' and 'V' (whatever the layout). Then, if these have not been typed, it checks for hardware key codes in the position of these letters on a 'normal' English keyboard. So it would not cope with the situation where a non-ASCII character in a different position is used for copy/paste/cut actions - but there has not (yet) been an real world issue raised about that. If that were a problem then some kind of lookup would probably be needed. Could you confirm whether Files works OK for you (with Dvorak keyboard).

[stan-janssen]

Pressing ctrl+C and ctrl+V in Files do nothing using a dvorak keyboard; pressing ctrl+J and ctrl+K (which are in the C and V places) also does not work. After switching to QWERTY, ctrl+C and ctrl+V do work for copying and pasting files.

[jeremypw]

@finetuned89 The quoted PR was reported to work by a Spanish Dvorak keyboard user so maybe there has been a regression since merging? Please file an issue against Files quoting which keyboard hardware and layout and locale you were testing with. Thanks.

[stan-janssen]

I filed issue https://github.com/elementary/files/issues/815 against Files.

[UlrichEckhardt]

I'm also affected by this misbehaviour, also on a Dvorak layout. I wonder, what does settings.natural_copy_paste do in above code and can I somehow unset that flag to work around this? That said, using Control+Insert to copy, Shift+Insert to paste and Shift-Delete to cut text is a good alternative to the Control-XCV triplet.

[UlrichEckhardt]

A little bit of research turned up this here: gsettings set org.pantheon.terminal.settings natural-copy-paste false For me, this works around the issue, though I haven't tested it extensively.