From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#11073: 24.0.94; BIDI-related crash in redisplay with certain byte sequences Date: Tue, 03 Apr 2012 09:02:52 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1333458246 10240 80.91.229.3 (3 Apr 2012 13:04:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 3 Apr 2012 13:04:06 +0000 (UTC) Cc: 11073@debbugs.gnu.org To: Kenichi Handa Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 03 15:04:05 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SF3P2-0002xd-NH for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Apr 2012 15:04:04 +0200 Original-Received: from localhost ([::1]:32979 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SF3P1-00076v-Oh for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Apr 2012 09:04:03 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SF3Op-0006Pi-T7 for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2012 09:04:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SF3Of-0007yu-Ms for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2012 09:03:51 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SF3Of-0007yo-JP for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2012 09:03:41 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SF3P0-0000YK-GF for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2012 09:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Apr 2012 13:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11073 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11073-submit@debbugs.gnu.org id=B11073.13334582002073 (code B ref 11073); Tue, 03 Apr 2012 13:04:02 +0000 Original-Received: (at 11073) by debbugs.gnu.org; 3 Apr 2012 13:03:20 +0000 Original-Received: from localhost ([127.0.0.1]:37797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SF3OI-0000XN-UN for submit@debbugs.gnu.org; Tue, 03 Apr 2012 09:03:19 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:55011) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SF3OF-0000XF-QW for 11073@debbugs.gnu.org; Tue, 03 Apr 2012 09:03:16 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKU/KE9soXt6/2dsb2JhbACBX5x7eYhwnhmGGQSbGYQJ X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="171657392" Original-Received: from 108-161-123-122.dsl.teksavvy.com (HELO pastel.home) ([108.161.123.122]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 03 Apr 2012 09:02:53 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id A457359322; Tue, 3 Apr 2012 09:02:52 -0400 (EDT) In-Reply-To: (Kenichi Handa's message of "Tue, 03 Apr 2012 14:55:11 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:58486 Archived-At: >> > 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). > 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. But isn't this (unify-charset 'big5 "MyBig5.map") performed in the .emacs? Is it really important to support adding unification rules after decoding took place? If so, why? And also, what about removing unification rules after decoding? Stefan