From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#11700: [O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables Date: Fri, 15 Jun 2012 11:38:08 +0300 Message-ID: <83lijpezrj.fsf@gnu.org> References: <83mx46y4f5.fsf@gnu.org> <837gv9y99l.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1339749566 28866 80.91.229.3 (15 Jun 2012 08:39:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 15 Jun 2012 08:39:26 +0000 (UTC) Cc: 11700@debbugs.gnu.org To: Dov Grobgeld Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 15 10:39:25 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SfS3t-0001tH-Rq for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Jun 2012 10:39:22 +0200 Original-Received: from localhost ([::1]:52073 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfS3t-0003Hy-P5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Jun 2012 04:39:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfS3p-00039R-TF for bug-gnu-emacs@gnu.org; Fri, 15 Jun 2012 04:39:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfS3j-0003Tp-Fj for bug-gnu-emacs@gnu.org; Fri, 15 Jun 2012 04:39:17 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfS3c-0003T1-PS; Fri, 15 Jun 2012 04:39:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SfS6T-00055i-VK; Fri, 15 Jun 2012 04:42:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Fri, 15 Jun 2012 08:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11700 X-GNU-PR-Package: emacs,org-mode X-GNU-PR-Keywords: Original-Received: via spool by 11700-submit@debbugs.gnu.org id=B11700.133974968719532 (code B ref 11700); Fri, 15 Jun 2012 08:42:01 +0000 Original-Received: (at 11700) by debbugs.gnu.org; 15 Jun 2012 08:41:27 +0000 Original-Received: from localhost ([127.0.0.1]:43658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SfS5u-00054z-JY for submit@debbugs.gnu.org; Fri, 15 Jun 2012 04:41:27 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:58657) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SfS5s-00054q-1l for 11700@debbugs.gnu.org; Fri, 15 Jun 2012 04:41:25 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M5N00J00GITI700@a-mtaout20.012.net.il> for 11700@debbugs.gnu.org; Fri, 15 Jun 2012 11:38:08 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M5N00JU5HBIM610@a-mtaout20.012.net.il>; Fri, 15 Jun 2012 11:38:07 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:61004 Archived-At: > Date: Fri, 15 Jun 2012 09:39:35 +0300 > From: Dov Grobgeld > Cc: 11700@debbugs.gnu.org > > Yes. Great! This is indeed what I wanted. My mistake was that I tried > it with a tab character before OR after the vertical bar. This > solution should be really simple to implement in org-mode as it means > that instead of joining the table columns with "" > as is currently done, you just need to use "" as well > as setting the tab width to 1. Yep. > But I just wonder, is there any other character (preferably white > space character) with the same end-of-segment-boundary properties as > tab, in case tab is used for something else in org-mode? That's the (space . :align-to COLUMN) display property I was talking about. With it, you can arrange for a single blank, say, to produce a stretch of whitespace of arbitrary size, in character cell units, aligned to a specified column. If you use :width instead of :align-to, you can have the size tuned in pixels. Emacs treats text covered by such display properties as segment separators, so they produce the same effect as TAB does. That's because conceptually, such display properties are used to separate text into columnar display, exactly like TAB is used in plain-text tables. You can find examples of using these display properties in minibuffer.el, where they are used to produce the display in the *Completions* buffer. Their documentation is in the ELisp manual. > Or is it possible to take an arbitrary character, e.g. U+E0020, and > bless it with end-of-segment boundary properties and then use that > in the org-mode buffer? Try using u+2029, it should do the trick, I think. > As a side note, I really like the idea of end of segment separator, > and I wasn't aware of it when I wrote fribidi a long time ago. I > wonder if the semantics of the emacs segment separator follows the > Unicode Bidi Algorithm? Of course, it does; Emacs implements the UBA to the letter, taking only the "high-level protocols" fire-escape to guide the reordering using Emacs-specific context. (But even the high-level protocols feature is part of the UBA, see section 4.3 there.) The Segment Separator feature is not an Emacs invention, it exists in the UBA. The key to understanding it is this part of the UBA: L1. On each line, reset the embedding level of the following characters to the paragraph embedding level: 1. Segment separators, 2. Paragraph separators, 3. Any sequence of whitespace characters preceding a segment separator or paragraph separator, and 4. Any sequence of white space characters at the end of the line. And the TAB character has "S", i.e. "segment separator", as its bidi property. Since its embedding level is reset to the base embedding level of the paragraph, the result is that text on both sides of a TAB is reordered separately and independently. Moreover, the high-level protocols feature give us one more possibility: HL4. Apply the Bidirectional Algorithm to segments. . The Bidirectional Algorithm can be applied independently to one or more segments of structured text. For example, when displaying a document consisting of textual data and visible markup in an editor, a higher-level process can handle syntactic elements in the markup separately from the textual data. Emacs uses this to treat the `space' display properties as segment separators.