[konsole] [Bug 423990] Implement "ModifyOtherKeys"

Jerôme Pouiller bugzilla_noreply at kde.org
Fri Sep 25 10:25:11 BST 2020


https://bugs.kde.org/show_bug.cgi?id=423990

--- Comment #1 from Jerôme Pouiller <jerome.pouiller at gmail.com> ---
I can get the expected behavior by adding all the key sequences to the keytab
file[1][2]:

   key A+Shift+Ctrl : "\E[65;6u"
   key A-Shift+Ctrl : "\E[65;5u"
   ...
   key *+Ctrl : "\E[42;5u"
   key 8+Ctrl : "\E[56;5u"

It works with vim. However, it breaks all other applications. I tried to keep
original behavior for already defined key sequences (ie. nearly all
<letter>-Shift+Ctrl and a few other ones).

Unfortunately, vim does not support that. Either it use ModifyOtherKeys and it
won't recognize <\x11> is same than <C-q> or it won't understand <C-S-q>[3][4].

If I understand right, the correct behavior would be use the ModifyOtherKeys
sequence only once Konsole has received '\E[>4;2m'[5]. Once ModifyOtherKeys is
enabled, it should be enabled for all the keys (Ctrl+A should send '\E[65;5u').

It is interesting to keep an eyes on other bug reports for the other terminals:
   - Gnome Terminal: https://bugzilla.gnome.org/show_bug.cgi?id=477068
   - iTerm2: https://gitlab.com/gnachman/iterm2/-/issues/5377
   - alacritty: https://github.com/alacritty/alacritty/issues/3101


[1] To keep thing simple, I have not add support for Alt modifier
[2] Note that I wasn't able to map keys ':' and '#' and using symbolic names
from Qt::Key neither works.
[3] Vim automatically enable the ModifyOtherKeys as soon as it receive one
ModifyOtherKeys sequence.
[4] A workaround is to use raw key sequences (eg. <Esc>[93;5u) instead of
symbolic control sequence (C-S-q) to define mapping.
[5] https://bugzilla.gnome.org/show_bug.cgi?id=730157#c1

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the konsole-devel mailing list