From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Tue, 16 Aug 2011 11:48:54 -0400 Message-ID: <87r54le4rd.fsf@stupidchicken.com> References: <4E48D309.6050503@acdlabs.ru> <83hb5jujjs.fsf@gnu.org> <874o1j10zv.fsf@fencepost.gnu.org> <8362lyvcli.fsf@gnu.org> <87fwl2r0l4.fsf@stupidchicken.com> <83zkjatnkz.fsf@gnu.org> <877h6et8oi.fsf@stupidchicken.com> <83vctxua2y.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1313509752 24100 80.91.229.12 (16 Aug 2011 15:49:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 16 Aug 2011 15:49:12 +0000 (UTC) Cc: dak@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 16 17:49:07 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QtLt2-0001Gt-G8 for ged-emacs-devel@m.gmane.org; Tue, 16 Aug 2011 17:49:04 +0200 Original-Received: from localhost ([::1]:51656 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtLt2-0003tK-1z for ged-emacs-devel@m.gmane.org; Tue, 16 Aug 2011 11:49:04 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtLsz-0003sz-Qq for emacs-devel@gnu.org; Tue, 16 Aug 2011 11:49:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QtLsy-0003u5-Tv for emacs-devel@gnu.org; Tue, 16 Aug 2011 11:49:01 -0400 Original-Received: from vm-emlprdomr-04.its.yale.edu ([130.132.50.145]:36648) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtLsu-0003qs-Di; Tue, 16 Aug 2011 11:48:56 -0400 Original-Received: from furball ([128.36.14.148]) (authenticated bits=0) by vm-emlprdomr-04.its.yale.edu (8.14.4/8.14.4) with ESMTP id p7GFmsUS005524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Aug 2011 11:48:55 -0400 In-Reply-To: <83vctxua2y.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 16 Aug 2011 09:47:17 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Scanned-By: MIMEDefang 2.71 on 130.132.50.145 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.132.50.145 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:143313 Archived-At: Eli Zaretskii writes: >> since there is no near-term solution, how bout turning off bidi >> display reordering for prog-mode buffers? > > What for? No one complained about it yet I think I mentioned in an earlier message that the presence of RTL characters mucks up the display of Emacs Lisp buffers. This happend to me while writing code containing RTL strings to test string-mark-left-to-right. > leaving it on helps find bugs and inefficiencies in the bidi display > engine. I understand your point, but it's not realistic to expect anyone to "find bugs and inefficiencies" in source code buffers right now. Those buffers aren't displayed in an intelligible manner, because they require missing "higher-level protocols" to display properly. It makes a lot of sense for Emacs 24.1 to provide just the "bare" UAX9 algorithm, enabled by default in text modes (where bare UAX9 will likely DTRT) and special modes (where Emacs can segment by hand if necessary); with the higher-level segmentation functionality postphoned to the next release. In prog modes, which require that higher-level segmentation functionality, it then makes sense to disable bidi display for now. This would also give a lot more time to study different ways of implementing segmentation (e.g. definining segmentation characters vs extending the bidi code to recognize text properties).