Re: Behavior of input method -- crdt.el

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I’ve done it with my hack (push forward the overlay input method
> uses) and it doesn’t block remote changes. It works with the
> builtin Chinese input method, and also a few external package I’ve
> tested. I don’t know if there's any problem with this approach.

I don't see anything wrong with the approach you're following.
It is disappointing that you'd need a special case for input methods.
I consider that as a "wart" which we'd like to be able to fix.
Maybe a good fix is to arrange for some kind of "protocol" that the
input method could use but that doesn't hard-code a dependency on the
input-method (i.e. a protocol that could be used by other packages
which may also want to modify the buffer temporarily while postponing
running the *-change-functions).

>> Hmm... That's clearly a problem.  I can imagine some reasons why we do
>> that, but I'm not sure they're good enough.  This probably deserves
>> a `M-x report-emacs-bug`.
> I don’t know, will it cause more problem if the input method
> actually trigger *-change-functions during halfway input?
> At least for my use case, that means the halfway input sequence
> is also synchronized to other peers and that doesn’t make much
> sense

I can't see any reason why it "doesn't make much sense".
I think it makes as much sense as any other "intermediate state" you
might go through while modifying some text.

> I think maybe the “correct” way is to display input sequence not
> as text in the buffer (conceptually they aren’t yet).

That's also a valid way to look at it, yes.


        Stefan