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: Buffer names with R2L characters Date: Tue, 21 Jun 2011 00:08:55 +0300 Message-ID: <834o3kw6qg.fsf@gnu.org> References: <838vswwk2b.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1308604324 24181 80.91.229.12 (20 Jun 2011 21:12:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2011 21:12:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: James Cloos Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 20 23:12:01 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 1QYllI-0002i8-KE for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2011 23:12:00 +0200 Original-Received: from localhost ([::1]:49536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYllH-0002ox-Ne for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2011 17:11:59 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYliO-0002Iv-J5 for emacs-devel@gnu.org; Mon, 20 Jun 2011 17:09:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYliM-0006sR-KW for emacs-devel@gnu.org; Mon, 20 Jun 2011 17:09:00 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:58957) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYliM-0006s1-3L for emacs-devel@gnu.org; Mon, 20 Jun 2011 17:08:58 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LN300800XAXHM00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Tue, 21 Jun 2011 00:08:56 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.124.66.211]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LN30083ZXEU9I90@a-mtaout23.012.net.il>; Tue, 21 Jun 2011 00:08:56 +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.175 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:140741 Archived-At: > From: James Cloos > Cc: Eli Zaretskii > Date: Mon, 20 Jun 2011 16:13:15 -0400 > > The bidi algorithm is just not designed for markup (and the tag > /is/ markup). No, it isn't. Not every use of '<' and '>' is markup. They can also be used in context such as "n > N" etc. They are just characters; XML did not appropriate them just because it uses them for markup. > Ideally there would be a 0-width break before the It's possible (we could use LRM), but it isn't ideal, because text terminals will have trouble displaying it. That's why I think using a character covered by invisible text property is better. > or a way to mark the blob as non-neutral. This feature is still far away. I thought about it, and concluded that implementing it is not trivial, or at least there were a couple of problems for which I couldn't think of a good solution yet. I don't think we should wait for such a feature and in the meantime display "12>FEDCBA>" as buffer name. I'd like to have a solution, even if an interim one, for Emacs 24.1. > Whether the result should display as <12>FEDCBA, <21>FEDCBA or FEDCBA<12>, > though, I have no idea. We can decide whatever we want (but not the one with "21": the order of digits in a number should be left to right). But any of these needs "help" to get them look like that, because the UBA simply cannot treat these cases gracefully. > I presume that a ordering break would result in the third. What's an "ordering break"? > For that to work the engine obviously needs to know what markup looks like, > which requires additional meta information about each document. The buffer > mode helps, but may not be sufficient? The Emacs reordering engine doesn't know anything about major modes, text properties, overlays, and other meta information. The only exceptions are (1) `display' properties and (2) buffer narrowing limits. This design is intentional, because otherwise the same code could not be used for reordering text independently of redisplay, e.g. for producing visual-order encodings, like if you wanted to print R2L text on a relatively dumb printer or send it to a process that doesn't grok bidi.