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 12:03:26 +0300 Message-ID: <83pqk5u3s1.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> <83vctxua2y.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1313485425 28334 80.91.229.12 (16 Aug 2011 09:03:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 16 Aug 2011 09:03:45 +0000 (UTC) Cc: cyd@stupidchicken.com, dak@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 16 11:03:39 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 1QtFYg-0004wI-J2 for ged-emacs-devel@m.gmane.org; Tue, 16 Aug 2011 11:03:38 +0200 Original-Received: from localhost ([::1]:59730 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtFYf-0005qD-SL for ged-emacs-devel@m.gmane.org; Tue, 16 Aug 2011 05:03:37 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtFYa-0005pm-92 for emacs-devel@gnu.org; Tue, 16 Aug 2011 05:03:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QtFYZ-0000Br-0s for emacs-devel@gnu.org; Tue, 16 Aug 2011 05:03:31 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:65368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtFYX-0000BW-7H; Tue, 16 Aug 2011 05:03:29 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LQ000500JT2OF00@a-mtaout21.012.net.il>; Tue, 16 Aug 2011 12:03:27 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.171.158]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LQ0005O7JTPNW10@a-mtaout21.012.net.il>; Tue, 16 Aug 2011 12:03:26 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.169 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:143289 Archived-At: > From: Andreas Schwab > Cc: Chong Yidong , dak@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Tue, 16 Aug 2011 09:40:45 +0200 > > Eli Zaretskii writes: > > > 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. > > They already exist: comment-start and comment-end, for example. These are strings, not characters. I meant single characters. Making that a string would make the job of implementing such a high-level protocol much harder, because the reordering engine always considers only one character, with a very few exceptions. Also, a segment cannot span more than a single line (up to a newline), so multi-line comments cannot use this solution. What I had in mind was not comments and strings in program source, but issues with display of foobar<1> buffer names and lines in mail-summary buffers, which I thought was what Chong had in mind. It could also be a solution for displaying XML, although that use case needs more thorough analysis, to see if this would really be a good solution. The key issue here is whether those same characters can appear in context where we do want them to be reordered as "normal" punctuation. If the answer is YES, then this idea won't hold water.