From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Tue, 16 Aug 2011 09:47:17 +0300 Message-ID: <83vctxua2y.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1313477253 14919 80.91.229.12 (16 Aug 2011 06:47:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 16 Aug 2011 06:47:33 +0000 (UTC) Cc: dak@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 16 08:47:28 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 1QtDQu-0003Dx-Eq for ged-emacs-devel@m.gmane.org; Tue, 16 Aug 2011 08:47:28 +0200 Original-Received: from localhost ([::1]:35233 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtDQt-0007HR-F1 for ged-emacs-devel@m.gmane.org; Tue, 16 Aug 2011 02:47:27 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtDQq-0007HM-U9 for emacs-devel@gnu.org; Tue, 16 Aug 2011 02:47:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QtDQp-0001t9-SM for emacs-devel@gnu.org; Tue, 16 Aug 2011 02:47:24 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:52304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtDQo-0001sn-3z; Tue, 16 Aug 2011 02:47:22 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LQ000900DFWFQ00@a-mtaout22.012.net.il>; Tue, 16 Aug 2011 09:47:19 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.171.158]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LQ0006SDDISNL32@a-mtaout22.012.net.il>; Tue, 16 Aug 2011 09:47:19 +0300 (IDT) In-reply-to: <877h6et8oi.fsf@stupidchicken.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:143277 Archived-At: > From: Chong Yidong > Cc: monnier@iro.umontreal.ca, dak@gnu.org, emacs-devel@gnu.org > Date: Mon, 15 Aug 2011 22:02:53 -0400 > > Eli Zaretskii writes: > > > More importantly, I don't think it's a good idea to change the bidi > > properties in such a radical way (or at all), because we don't have > > the resources to investigate all of the consequences. For example, < > > is a mirrored character, so when it's between to R2L characters, it > > displays as > and vice versa. Yes, I know: you'll suggest to change > > the mirroring table as well, but how far should we go? do we really > > want to create our own UBA? > > The specs allow for a "higher level protocol" to segment text according > to what makes sense for (say) Lisp syntax, so anything that displays > most realistic Lisp code correctly would be good enough. "Higher level protocols" don't include futzing with bidirectional properties of characters. "Higher level protocol" means some means to determine segment boundaries other than segment separator characters that are part of the text. Translated into Emacs-speak, this means we need a variable that, when bound to some special value, instructs the reordering engine to treat certain characters as segment separators. > I guess this is not realistic to implement for 24.1 If we go with a variable described above, it's actually a very simple job, so just say the word. However, I suggest that before doing this we come up with a more detailed plan: suppose you have this variable, how would you solve the problems discussed here with its help? The devil is in the details. > 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, and leaving it on helps find bugs and inefficiencies in the bidi display engine. So my vote is NAY.