The bug <http://www.lyx.org/trac/ticket/9362> causes the keyboard to malfunction and consistently causes deadlocks with data loss.
I've finally narrowed down the issue to the fact that LyX is currently incompatible with IBus and in particular its asynchronous mode. The setting is stable & master, and X11 + IBus. There are two faulty behaviours: 1. Erroneous keyboard input and deadlock, after LyX has been overwhelmed by key events. 2. Move commands continue way after the arrow key has been released. Normally, excess move commands are ignored and the message: "GuiWorkArea.cpp (1053): system is busy: scroll key event ignored" is shown with "lyx -dbg key". With this bug, the message does not appear. I observe the following: * With asynchronous IBus, we have both issues 1 & 2. IBus is asynchronous by default in Ubuntu. * With synchronous IBus, we only have the issue 2. IBus can be set synchronous with the command: IBUS_ENABLE_SYNC_MODE=1 ibus-daemon --xim --replace * Without ibus, there is no issue. IBus can be disabled just for LyX with the command: XMODIFIERS= src/lyx According to a quick internet search, asynchronous IBus functionality is necessary for the Hangul input method to function properly. So there are really two bugs: a. LyX should be fixed to support IBus. b. Key event compression should be implemented properly. If it is really done properly, then the responsiveness of LyX could be improved greatly; it would mean e.g. treating repeated rightarrow keypresses as a single LyX event "forward-char n" without updates in between, and chuncks of texts would be input at once. Is there any technical difficulty for implementing b.? Here are a few links I gathered: About a similar issue with Android Studio and its workaround at user level: <https://stackoverflow.com/questions/30756488/keyboard-issues-with-android-studio-on-ubuntu> About a similar issue in Chromium and its workaround at application level: <https://src.chromium.org/viewvc/chrome/trunk/src/ui/base/ime/input_method_linux_x11.cc?r1=237027&r2=237026&pathrev=237027> About a longer-term solution in Chromium: <https://codereview.chromium.org/224723008> About the inappropriateness of checking hasPendingEvents() to perform event compression (cf. GuiWorkArea::keyPressEvent()) <https://stackoverflow.com/a/21488676> <https://bugreports.qt.io/browse/QTBUG-36611?focusedCommentId=230881&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-230881> About setting Qt::WA_KeyCompression to enable key event compression (unfortunately only for printable characters): <http://doc.qt.io/qt-4.8/qt.html#WidgetAttribute-enum> About various solutions for implementing compression for other kinds of events: <https://stackoverflow.com/a/20939793>
