From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.bugs Subject: bug#11073: 24.0.94; BIDI-related crash in redisplay with certain byte sequences Date: Fri, 06 Apr 2012 10:13:12 +0900 Message-ID: References: <83sjgzvb6w.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1333674821 4194 80.91.229.3 (6 Apr 2012 01:13:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 6 Apr 2012 01:13:41 +0000 (UTC) Cc: 11073@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 06 03:13:39 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 1SFxk8-0004Hc-33 for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Apr 2012 03:13:36 +0200 Original-Received: from localhost ([::1]:48141 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFxk5-000723-H5 for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Apr 2012 21:13:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFxk2-0006zf-1o for bug-gnu-emacs@gnu.org; Thu, 05 Apr 2012 21:13:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFxjz-0000wF-Dl for bug-gnu-emacs@gnu.org; Thu, 05 Apr 2012 21:13:28 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFxjz-0000wA-AU for bug-gnu-emacs@gnu.org; Thu, 05 Apr 2012 21:13:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SFxkY-0000sj-Gx for bug-gnu-emacs@gnu.org; Thu, 05 Apr 2012 21:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Kenichi Handa Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Apr 2012 01:14: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.13336748363370 (code B ref 11073); Fri, 06 Apr 2012 01:14:02 +0000 Original-Received: (at 11073) by debbugs.gnu.org; 6 Apr 2012 01:13:56 +0000 Original-Received: from localhost ([127.0.0.1]:41893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SFxkS-0000sI-8r for submit@debbugs.gnu.org; Thu, 05 Apr 2012 21:13:56 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:56823) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SFxkO-0000s7-T2 for 11073@debbugs.gnu.org; Thu, 05 Apr 2012 21:13:55 -0400 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id q361DECn008100; Fri, 6 Apr 2012 10:13:14 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id q361DE7w020364; Fri, 6 Apr 2012 10:13:14 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp4.aist.go.jp with ESMTP id q361DCXJ021330; Fri, 6 Apr 2012 10:13:12 +0900 (JST) env-from (handa@m17n.org) In-Reply-To: (message from Stefan Monnier on Tue, 03 Apr 2012 21:17:16 -0400) 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:58542 Archived-At: In article , Stefan Monnier writes: >>> But isn't this (unify-charset 'big5 "MyBig5.map") performed in the .emacs? > > Usually yes. But, in that case, if .emacs is encoded in > > Big5 and it contains some Big5 PUA chars, they are not > > unified while loading .emacs. > Hmm... that doesn't sound like it would be a very common problem, but > it's not completely hypothetical either. Would this problem also come > up in a BIG5 locale? If not, then I think we can ignore this problem. If it ever comes up, it is mostly for people in BIG5 locale. But, please note that the reason I used BIG5 as an example is just because that charset name is short. Almost all CJK charsets have PUA (officially or just by convention). >>> Is it really important to support adding unification rules >>> after decoding took place? If so, why? > > As I wrote, I can't tell how important it is. It may be very > > important for those (but I guess very few) who need the above > > operation, but not important for the majority. > > I'm ok to remove such a feature if the maintainers decide that. > The problem with it is that it costs all the time for everyone, and it I believe the extra cost is almost negligible because such (dynamic) unification happens only for characters that is greater than MAX_UNICODE_CHAR. > makes the behavior of some macros subtly more complex/different and > hence adds a nasty complexity. That's mostly because I didn't write a proper comments on the relavant macros, and didn't provide a better macros for such a case as Eli's. > So if at all possible, I'd rather find a way to remove it (not for > 24.1, obviously). I myself think that it doens't cause much problem even if we keep this functionality, but, also don't raise strong objection to remove it for 24.2. >>> And also, what about removing unification rules after decoding? > > When one tells Emacs to unify some chars, and then reads a file > > containing those chars, there's no way to dis-unify them. > But I guess this problem is even much less common. Yes. That's why I didn't implement such a feature. --- Kenichi Handa handa@m17n.org