Re: quail inserts raw characters on unfinished sequences

[Juri Linkov]

> 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/