From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bidi,gmane.emacs.devel Subject: Re: improving bidi documents display Date: Sun, 27 Feb 2011 23:15:12 +0200 Message-ID: <83aahhnpr3.fsf@gnu.org> References: <837hcpryxr.fsf@gnu.org> <87wrklpzii.fsf@maru.md5i.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1298841335 17561 80.91.229.12 (27 Feb 2011 21:15:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 27 Feb 2011 21:15:35 +0000 (UTC) Cc: eli.osherovich@gmail.com, emacs-bidi@gnu.org, emacs-devel@gnu.org To: Michael Welsh Duggan Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Sun Feb 27 22:15:30 2011 Return-path: Envelope-to: gnu-emacs-bidi@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ptnxh-0006rG-LO for gnu-emacs-bidi@m.gmane.org; Sun, 27 Feb 2011 22:15:29 +0100 Original-Received: from localhost ([127.0.0.1]:51872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ptnxh-0006PN-4l for gnu-emacs-bidi@m.gmane.org; Sun, 27 Feb 2011 16:15:29 -0500 Original-Received: from [140.186.70.92] (port=39759 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ptnxa-0006PD-3J for emacs-bidi@gnu.org; Sun, 27 Feb 2011 16:15:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PtnxV-0006rp-8H for emacs-bidi@gnu.org; Sun, 27 Feb 2011 16:15:22 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:52295) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PtnxU-0006rg-6W; Sun, 27 Feb 2011 16:15:17 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LHA00400O527000@a-mtaout20.012.net.il>; Sun, 27 Feb 2011 23:15:10 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.183.216]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LHA0046OOD44U20@a-mtaout20.012.net.il>; Sun, 27 Feb 2011 23:15:10 +0200 (IST) In-reply-to: <87wrklpzii.fsf@maru.md5i.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.166 X-BeenThere: emacs-bidi@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of Emacs support for multi-directional text." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Errors-To: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bidi:844 gmane.emacs.devel:136582 Archived-At: > From: Michael Welsh Duggan > Cc: Eli Osherovich , emacs-devel@gnu.org, emacs-bidi@gnu.org > Date: Sun, 27 Feb 2011 05:01:25 -0500 > > Memory: HEBREW \foo{english} > Levels: 11111111222222222221 > Display: {foo{english\ WERBEH The key to a useful discussion of these matters is to decide up front what do we want to support and what do we want the text to look like. In this case, someone who knows about (La)TeX much more than I do should first describe what TeX features would be useful when typesetting bidirectional text. With that knowledge in hand, we could then think whether the example above is at all practical. For example, most of the problems go away if paragraphs have left-to-right direction; in that case the display will be WERBEH \foo{english} Maybe this is already good enough. > One simple, naive way of handling this for the various TeXs is to > consider all backslashes and brace characters as R characters. This can > be simulated by surrounding each run of these characters by LRE PDF > pairs. However, unless TeX ignores these characters completely, these > formatting characters would have to be removed before being processed by > TeX. Again, someone who knows should tell if the bidi formatting codes need to be removed before TeX'ing the file. > Another way of handling this would be to redefine the backslash and > brace characters as R characters, for purposes of the display engine. > Currently, I don't know if there is a way to do this in elisp. bidi.c > seems to use a character table named bidi_type_table to hold this > information. Currently this table is not exposed at the elisp layer, to > the best of my knowledge. Maybe it would be possible to modify this > table in elisp, and possibly make it buffer local? I didn't expose the table to Lisp on purpose: messing with bidirectional properties of characters is asking for trouble. At best, you will get text that will look different in any other editor; at worst, you could easily crash Emacs. > Another idea would be to allow a text property to override the character > type. Overlay, not text property. The latter modifies the buffer, which is not what you want in this case. > This feels like a very elegant, emacs-ish way to do things, but > an uneducated glance at the bidi code makes me feel like it would be > difficult to get information about text properties into this layer. You are looking at this from a wrong perspective. The bidi reordering engine doesn't need to access text properties or overlays; rather, the display code should tell the reordering engine what to reorder. The reordering code already honors point-min and point-max, so all it takes to do what you want is narrow the buffer to the portion of text we want to reorder. These portions could be marked by an overlay; the display code already examines overlays as it goes about its job. > Another idea would be to use display strings including the LRE and PDF > characters to replace existing backslashes and braces. However, display > strings do not affect the bidi algorithm at this point. I need a few rainy days to implement support for display strings. However, it would be a mistake to base large portions of buffer display on display strings, because they make redisplay too expensive.