[Top][All Lists]

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

Re: Feature freeze on October 1

From: Kenichi Handa
Subject: Re: Feature freeze on October 1
Date: Sun, 23 Sep 2012 11:05:12 +0900

Very sorry for the late response on this matter.

In article <address@hidden>, Eli Zaretskii <address@hidden> writes:

> > From: Stefan Monnier <address@hidden>
> > Cc: address@hidden, address@hidden, address@hidden
> > Date: Mon, 17 Sep 2012 15:36:42 -0400
> > 
> > >> AFAIK unification is already performed when we read a char from
> > >> outside Emacs
> > > Where does that happen in the code?
> > 
> > I assume it's done in the coding-system's decoding code.


> But that doesn't get run (or at least not always) when a character is
> typed on the keyboard, does it?  E.g., on MS-Windows characters are
> read directly in Unicode when possible.  I'm sure Emacs does something
> like that on X as well.

> So it looks like some un-unified characters can still sneak into the
> buffer.

On X, Emacs uses X input method which returns characters
encoded in the current locale, and thus Emacs decodes them
by Vlocale_coding_system.  So, the unification should be
done here too.

> > so maybe all it takes is to remove the maybe_unify_char thingy?

> Not sure that's all.  I hope Handa-san could outline the plan for
> attacking this problem, then maybe I could work on at least part of
> that, if not all of it.

I have not yet figured out in detail the effect, but, what
should be done, I think, is to remove the call of
MAYBE_UNIFY_CHAR in char_string and string_char of

Kenichi Handa

reply via email to

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