SUMMARY The ~/.Xmodmap key remapping is ignored by KPart. The key remappings works in bash, in non-KDE software, in KDE software (e.g. search field of System Settings). Partially works in Calligra. STEPS TO REPRODUCE - Fill ~/.Xmodmap with the content given below - Logout and login (or run xmodmap ~/.Xmodmap) - Type CAPS_LOCK+l in Kate OBSERVED RESULT Nothing happens EXPECTED RESULT Cursor moves to the right SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.15.5 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.3 Kernel Version: 4.19.49-1-MANJARO ADDITIONAL INFORMATION My ~/.Xmodmap is as follows: keycode 66 = Mode_switch keysym h = h H Left Left ugrave Ugrave keysym l = l L Right Right keysym k = k K Up Up keysym j = j J Down Down
This is handled by Qt. There are up-stream bugs for this, e.g. https://bugreports.qt.io/browse/QTBUG-31527?jql=text%20~%20%22xmodmap%22 Most of them seem to be closed, if that still happens, please re-open one of them there. Sorry for the inconvenience, Kate/KTextEditor can't fix that.
I have built a basic QApplication with a QTextEdit component to test this, and things are working, so I believe this is not a Qt bug. Moreover, in other parts of KDE this bug is not present. For example the text editor of KMail does not have this problem and neither the line edits of all the system settings modules. Actually, things are also working in Calligra Words (not sure why I said they are only partially working).
Thanks for trying this! The question is: What is the difference between QTextEdit and our event handling. We only handle the key events Qt passes to us, too :/
Ok, btw., we have an older bug for such key handling issues. I will duplicate this to the older one. Still, nobody has brought up some proper solution :( *** This bug has been marked as a duplicate of bug 378178 ***