Re: Timing of input-method output

[phillip.lord@russet.org.uk (Phillip Lord)]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Hmm... this is a bummer (in some input methods, many/most chars are
>>> prefixes of something else).  IIUC this is not a new problem introduced
>>> by the use of input-event-functions, tho, right?
>> My experience is that completion doesn't work when an input method is
>> half way through, although I only use simple input methods.
>
> Right: so this is not a new problem.

Based on the limited evidence of me poking the one input method I use
with a stick, no.


>> Anyway, I checked (should have done this before I sent the last email,
>> sorry). The buffer is not changed by an input method half way through
>> (or at least "before-change-function" is not called, which I am assuming
>> is the same thing). So, when the buffer appears to say "pizza_[`]", if
>> it does offer a completion at all, it's going to offer one based on
>> "pizz" because they "a" is not in the buffer.
>
> Actually, quail.el does insert the "a", but it does so only temporarily,
> within a with-silent-modification, and it removes it as soon as we know
> what will actually be the next result of the input method (to the user,
> that's basically when the underscore is (re)moved).
>
> IOW, the underlined text behaves more or less like it's not in the
> buffer (technically it is, but it's transient and the *-change-functions
> aren't notified).
>
> For latin-based input methods (especially postfix-style ones) where it's
> extremely frequent for the first char passed to an input method to end up
> passed through unmodified, it would make sense to try and change the
> behavior of quail so it really inserts the first char right away, even
> if it may later modify it because of some subsequent user input.
>
> E.g. currently, in latin-postfix methods, when I type
>
>     Time0   Time1
>     -----   -----
>     e       n
>
> the input looks (to the rest of Emacs) as if I had typed
>
>     Time0   Time1
>     -----   -----
>             e n
>
> this is so that when I type
>
>     Time0   Time1
>     -----   -----
>     e       '
>
> Emacs only sees
>
>     Time0   Time1
>     -----   -----
>             é
>
> but we it would make sense to try and make it behave such that an input like:
>
>     Time0   Time1   Time2   Time3
>     -----   -----   -----   -----
>     e       n       e       '
>
> results in the following (decoded) input events:
>
>     Time0   Time1   Time2   Time3
>     -----   -----   -----   -----
>     e       n       e       DEL é
>
> [ More or less: the DEL there can't be right since the user can bind it
>   to anything else, so we'd have to delete the previous char "manually"
>   rather than by emitting a DEL event.  ]
>
> This would be a pretty significant change in quail.el (which is likely
> to require experimentation before we can find something that works
> well), and is likely to only make sense in some input methods.
>
> I think it'd be nice for someone to play with such a quail variant
> (it's probably easiest to do it be adding a config var to quail.el to
> control that new behavior) to see if it can fly.

I think that this would work more cleanly. In this case, at Time 2 we
would be offering a completion for prefix "ene" rather than "ene'" which
should then be functional with a [tab] (or whatever) at Time 3. And,
yes, that DEL would also need to be special, also not to appear in the
undo list, since we would want the events to appear to be "ene'" and not
have a DEL in the middle.

One question I would have wrt to completion is whether and how input
methods affect the visualisation of the buffer. For example, the one I
use puts an underline underneath the "e". This clearly needs to happen
at the right time so it doesn't break the visualisation that both
company and pabbrev drop into the buffer (it's the visual artifact that
made me investigate this all in the first place).

Having said all this, I am currently struggling to get the
input-event-functions to function properly for my use case -- I have got
it stopping the strange visualisation, but alas, at the cost of breaking
completion which is a baby-and-bathwater thing. The reason for this is
that I use `this-command' to work out whether to remove the completion
or not and `input-event-functions' runs before this is set.

Is there any way of knowing whether quail is currently offering a choice
of input?
`quail-is-waiting-for-another-keystroke-to-work-out-what-to-do-p'
perhaps?

Phil