[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14368: 24.3.50; Big screw: multibyte characters become unibyte

From: Handa Kenichi
Subject: bug#14368: 24.3.50; Big screw: multibyte characters become unibyte
Date: Fri, 24 May 2013 10:51:20 -0400

I'm very sorry for the late response on this matter.

In article <address@hidden>, Eli Zaretskii <address@hidden>
> However, quail seems to work by deleting some characters from the
> buffer, and then reinserting them, possibly after translation, as
> instructed by the additional characters you type.  In this case,
> typing "a '" inserts á, and quail then waits for another character.
> Typing C-a at this point removes á from the buffer, and then sends as
> input 2 events: a self-inserting character whose code is 225 decimal
> (that's á), followed by the code 1, which is C-a.  (I don't know if
> this is how quail is supposed to work; what I described is what I saw
> in the debugger.  Perhaps Handa-san could comment on that.)

Your analysis is correct.  Quail is an event translator.  It
is designed not to insert a character directly but to
generate proper character events.

> I'm not sure how to fix this cleanly.  One way would be to get quail
> to encode the character events it sends, but then we have problems
> with un-encodable characters.

It is a possible way, but I don't think that is the right
thing.  Making quail encode characters and making the caller
to re-decode them looks like very silly.

> Another way would be to somehow detect
> that the character comes from quail and refrain from decoding it,

It's not only the quail problem.  Currently the handling of
unread-command-events is broken; this does not work correctly on
   (setq unread-command-events '(?À))

Kenichi Handa

reply via email to

[Prev in Thread] Current Thread [Next in Thread]