Dear Maintainer, Recently the ‘rfc1345’ input method (provided by ‘ibus-m17n’) has captured unrelated keystrokes, which interfere with normal operation. The only “escape” character documented for ‘rfc1345’ input method is the ‘&’ key, and that still functions as an escape key as expected. (For example, typing ‘&’ ‘P’ ‘I’ produces “¶”.) No other keystrokes should be intercepted by the ‘rfc1345’ method without being preceded by that ‘&’ keystroke. But current versions also capture ‘/’ and ‘Ctrl+U’ (and perhaps others I have not discovered). Those keystrokes then do not behave as normal keystrokes in applications. For example, typing ‘/’ now does not reliably produce a ‘/’ character; it sometime acts as an escape key. And typing ‘Ctrl+U’ apparently expects a sequence of numerals to produce a Unicode code point; if it is not followed by numerals, instead of the intended Ctrl+U event, it inserts “U+”. Please restore the normal behaviour of all keystrokes other than the escape character ‘&’ when the ‘rfc1345’ input method is selected.
Control: found -1 ibus/1.5.11-1 This continues to happen after the upgrade to ‘ibus’ version “1.5.11-1”. What can be done to diagnose the cause of this unwanted behaviour?
Pressing ‘/’ will not send the ‘/’ keystroke to the terminal, but instead waits as though that is a prefix for the next keystroke. This is completely unwanted with “rfc1345”, as originally reported. What is new now is that the keystrokes are sent in the wrong order. For example, pressing ‘/’ then ‘q’ will result in the terminal receiving the sequences in reverse order. So typing “/quit” sends “q/uit”. Please investigate what has regressed to make ‘/’ and ‘Ctrl+U’ (and anything except ‘&’) behave like unwanted prefix keys.
Control: reassign -1 m17n-db Control: found -1 m17n-db/1.7.0-2 This regression seems to be explicitly caused by code in ‘/usr/share/m17n/global.mim’: ===== (fallback-input-method (_"Fallback input methods. Value must be comma separated fallback input method names. When you type a key that is not handled by the currently activated intup method, fallback input methods (in the order specified in this variable) try to handle that key, and the first one that can handle the key is activated temporarily. For instance, as the default value of this variable is \"lsymbol, unicode\", when you type \"/...\" while you are activating an input method that doesn't handle that key sequence, \"lsymbol\" input method is activated and \"…\" (U+2026: HORIZONTAL ELLIPSIS) is inserted.") "lsymbol, unicode")) ===== Please reverse this change, and restore the behaviour of earlier versions: only enable input methods explicitly requested by the user.
I've emailed upstream to get their thoughts on this bug. cya, #
Feedback from upstream:
Now, the default value of fallback-input-method is "lsymbol, unicode".
So all input methods (not only rfc1345) are given mapping for "/" (from
lsymbol.mim) and "C-u" (from unicode) unless they themselves define
mappings for those characters.
If a user does not like this feature, one can customize the value of
fallback-input-method defined in global input method to an empty string
by using the tool "m17n-im-config", or by having this code in
~/.m17n.d/config.mic.
((input-method t nil global)
(variable
(fallback-input-method nil
"")))
Ping; what are the prospects for resolving this and restoring the behaviour previous to this bug? Meanwhile, the workaround I have is: ===== $ package_data_dir=/usr/share/m17n $ local_data_dir=/usr/local/share/m17n $ sudo mkdir $local_data_dir $ sudo cp $package_data_dir/global.mim $local_data_dir/ $ edit $local_data_dir/global.mim [… change the file according to the patch below …] $ diff -u /usr/share/m17n/global.mim /usr/local/share/m17n/global.mim --- /usr/share/m17n/global.mim 2015-08-27 21:54:11.000000000 +1000 +++ /usr/local/share/m17n/global.mim 2016-01-17 11:12:51.465276670 +1100 @@ -53,7 +53,7 @@ when you type \"/...\" while you are activating an input method that doesn't handle that key sequence, \"lsymbol\" input method is activated and \"…\" (U+2026: HORIZONTAL ELLIPSIS) is inserted.") - "lsymbol, unicode")) + nil)) (command (commit $ sudo ln --symbolic --relative $local_data_dir/global.mim $package_data_dir/. ===== After re-starting the desktop, the m17n input methods behave correctly with no interference from unwanted methods. This is not a satisfactory solution though, because the next upgrade of the package will overwrite the changes. The correct fix is to change the ‘/usr/share/m17n/global.mim’ file in the package, to match the change above.
is in the default settings. The default seetings cause hard-to-diagnose bugs, that someone who is not a programmer would have no hope of finding out what's wrong. They are a regression from the previous behaviour. Please work with upstream to get it fixed there, and in the meantim patch the defaults in Debian so the default settings do not enable unwanted input methods.
I've added Kenichi (upstream) to this email thread. You can discuss it directly with him. cya, #
Control: retitle -1 m17n-db: Global settings enable unexpected input methods Control: owner -1 ! Control: tags -1 + upstream Control: found -1 m17n-db/1.8.0-3 Kenichi, I assume you have now had the opportunity to read this email discussion (Debian bug#799666 <URL:https://bugs.debian.org/799666>). The bug in global settings – unexpected input methods are default enabled which mess up keyboard input without explanation – continues with ‘m17n-db’ version 1.8.0. What further information do you need to revert this change so that the database by default enables *no* input methods except those explicitly selected?