Re: Feature freeze on October 1

[Kenichi Handa]

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.

Yes.

> 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
character.c.

---
Kenichi Handa
address@hidden