> Ah, it seems that the fix you want and the fix I've done are > different. You wrote: > >>> When the input sequence "shc" is completed, the result >>> should be "шц", ... > > Quail knows that "shc" is completed only when it accepts > more characters (e.g. " ", "."). So, I fixed that case. > Please try to type "shc shc.". "шц шц." should be inserted.
Yes, finishing it with " " or "." works, but this doesn't look useful for me, because finishing it with many other keys (point movement keys like `C-f', or even toggle-input-method key `C-\') leave latin "c" untranslated. > But, it seems that what you want is to show "шц" as soon as > you type "shc". I'm not sure it's a good user interface. I think it's a good user interface when quail shows the same characters that will remain in the buffer if the user finishes the input sequence (even incomplete). > When "ц" is shown, doesn't a user expect it to be changed to > "ч" when he types another "h" (because "ch" sequence is > mapped to "ч")? The user may expect "ц" to be changed to "ч" only for the full sequence "ch", but not inside "shch". When the user has the intention to type "щ", then the sequence "shch" is typed without looking at intermediate results that every character may produce. But even when the user forgets about the typed character, then the echo area always displays the input sequence, so the echo area with "shc[h]" will tell that the next typed character "h" will produce "щ", not "шч". >> I looked a bit at quail.el and managed to change it to work with the >> described case using the fix below. Please review this fix very >> carefully, since I am not familiar with the quail code at all, and >> it may break something else. > > It seems that the change is incomplete. At least it should handle > the case that `str1' is nil, perhaps by trying to lookup shorter keys. This could be fixed, when you agree with the change. > By the way, having this kind of a problem means that the > input method is not well designed. I looked at other input methods, but can't find a similar case where an unfinished sequence doesn't have a rule, but its last raw character can be translated to another target character. But I think this doesn't mean that the input method is not well designed. I must say that this input method is highly unambiguous. So rather I'd say that this case provides an opportunity to fix quail to support such input methods. -- Juri Linkov http://www.jurta.org/emacs/ _______________________________________________ Emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
