[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