GNU bug report logs - #11073
24.0.94; BIDI-related crash in redisplay with certain byte sequences

Previous Next

Full log

Message #41 received at 11073 <at> debbugs.gnu.org (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: eliz <at> gnu.org, 11073 <at> debbugs.gnu.org
Subject: Re: bug#11073: 24.0.94;
	BIDI-related crash in redisplay with certain byte sequences
Date: Tue, 03 Apr 2012 14:55:11 +0900

In article <jwvwr5xwimc.fsf-monnier+INBOX <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> > Please note that not all characters in the code-space of a
> > CJK charset are unified.  For instance, Big5 has it's own
> > PUA (private use area), and characters in PUA are not
> > unified by default.  So, if Emacs reads a Big5 file that
> > contains PUA chars, those chars stay in high-area.   Then,
> > one can provide his own unification map that also maps PUA
> > chars to some Unicode chars as this:
> >   (unify-charset 'big5 "MyBig5.map")
> > After this, I thought that previously read PUA chars staying
> > in the high-area should be treated as the corresponding
> > Unicode chars (in displaying, search, etc).

> But again, this unification takes place during decoding.

No.  In the above scenario, PUA chars read before the call
of unify-charset are not unified.  The unification should
take place after the call of unify-charset.

> Whereas what
> I'm talking about takes place when reading the internal utf-8
> representation, which should be already unified.

I'm talking about exactly that case.

---
Kenichi Handa
handa <at> m17n.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.