From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jambunathan K Newsgroups: gmane.emacs.devel Subject: Re: Emacs as word processor / Text Properties Date: Fri, 29 Nov 2013 19:12:32 +0530 Message-ID: <87d2ljwchj.fsf@gmail.com> References: <87vbzqfgd6.fsf@uwakimon.sk.tsukuba.ac.jp> <8338mmcsd9.fsf@gnu.org> <83txf1blf2.fsf@gnu.org> <87txf133yd.fsf@zigzag.favinet> <83r4a5bj5x.fsf@gnu.org> <87mwktdy6r.fsf@uwakimon.sk.tsukuba.ac.jp> <83iovhb0ez.fsf@gnu.org> <87k3fxdpmg.fsf@uwakimon.sk.tsukuba.ac.jp> <837gbwbcsx.fsf@gnu.org> <87d2lnevq7.fsf@uwakimon.sk.tsukuba.ac.jp> <87ob57rlkb.fsf_-_@informatimago.com> <35e892b1-73b8-4ca2-9317-7eb83e7223e5@default> <464a688e-b7a5-4f6b-84b4-d7cd42107c8d@default> <87li074mxc.fsf@gmail.com> <83zjon7evk.fsf@gnu.org> <8761rb4jts.fsf@gmail.com> <83pppj77r4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1385732900 9740 80.91.229.3 (29 Nov 2013 13:48:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Nov 2013 13:48:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 29 14:48:23 2013 Return-path: Envelope-to: ged-emacs-devel@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 1VmOQd-0000bP-TE for ged-emacs-devel@m.gmane.org; Fri, 29 Nov 2013 14:48:20 +0100 Original-Received: from localhost ([::1]:47439 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmOQd-0007gz-IQ for ged-emacs-devel@m.gmane.org; Fri, 29 Nov 2013 08:48:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39730) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmOM9-0000AR-6Q for emacs-devel@gnu.org; Fri, 29 Nov 2013 08:43:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VmOM0-0006N3-NQ for emacs-devel@gnu.org; Fri, 29 Nov 2013 08:43:41 -0500 Original-Received: from mail-pb0-x22d.google.com ([2607:f8b0:400e:c01::22d]:35646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmOM0-0006KX-BA; Fri, 29 Nov 2013 08:43:32 -0500 Original-Received: by mail-pb0-f45.google.com with SMTP id rp16so14457909pbb.4 for ; Fri, 29 Nov 2013 05:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=s+XWsGj9fhrDC0zTbwSbHqSJ791VWz10ddMuIl1RCF8=; b=t2BysNyGSnCvsEwAF+MHOcZRhwBGl/d/uKXW1IUSDzWtDfRvMq7JvfHaApBwDoNM17 5If6Pvj4IOgqvwhKcDAh+drJuc9TwJT4Y6cHdvK3U9+rVu0T+ggL/ER/mAwQ9SAkw7zH o/coGq0LHrQhGrMRqmq4dyvRMKlts1KN4iDkw/BUl9jp0NdjLUyzQ2McFXpMXLT93KJ6 Zk6doXKm6irGBabSqvXkyUwZwnDAr8T50ONehMmQtvZKtdekyI6cPLb8slOVh2Ia8mfE nh4ur2tYWBSOR6LUD/t2bF9VkftVG1Cs5/gCu7G8F8VjMf5EVzJ/RZUCgF6RUUHyhb0F tHpg== X-Received: by 10.66.248.227 with SMTP id yp3mr33119396pac.116.1385732610772; Fri, 29 Nov 2013 05:43:30 -0800 (PST) Original-Received: from debian-6.05 ([115.241.66.53]) by mx.google.com with ESMTPSA id qz9sm101015748pbc.3.2013.11.29.05.43.27 for (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Fri, 29 Nov 2013 05:43:29 -0800 (PST) In-Reply-To: <83pppj77r4.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 Nov 2013 13:43:59 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c01::22d 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:165869 Archived-At: Thanks for the note. >> ps: When I ask this question, I assume that the people who wrote the >> standards have gooed enough reasons tag paragraphs as RTL or LTR >> "explicitly". > But until and unless someone explains why inserting invisible control > characters is not enough I don't know. You are saying that explicit markers could be used in place of per-paragraph tagging to achieve the desired effect. May be it is not a question of "enough" but a question of "manageable". i.e., minimizing or eliminating undesired effects while moving - copy + pasting - the text around. The FAQ below talks about avoiding paired control codes (to avoid goofing up of structure) and says RLM and LRM are "less problematic". So, the question is were you surprised (or annoyed) by unexpected directionality when copy-pasting text that have markers. Will use of per-paragraph specification minimize the associated headaches. ,---- http://www.w3.org/International/questions/qa-bidi-controls.en.php | | To correctly format bidi text in (X)HTML or XML content, should I use | Unicode control codes or markup? | | [snip] | | In (X)HTML and XML do not use the paired Unicode bidi formatting code | characters where equivalent markup is available. | | Reasons | | When control characters are used in free-flowing content there is always | a likelihood of overlapping or unterminated ranges - especially because | the characters themselves have no visible form. If attributes are used, | this is not an issue in well-formed markup. | | It is also much easier to manage inheritance and the effects of | paragraph separators with markup. Using Unicode controls results in a | lot more work to achieve the same result. Also it is difficult to know | how to achieve effects like reversing table columns and right-aligning | text with just Unicode control codes. | | The HTML 4 specification specifically warns against mixing the two | approaches because of the increased likelihood of improper nesting. It | also recommends the use of markup because it "offers a better guarantee | of document structural integrity and alleviates some problems when | editing bidirectional HTML text with a simple text editor". It does not | proscribe the use of Unicode bidi formatting codes. | | The joint Unicode Technical Report #20 and W3C Note, Unicode in XML and | other Markup Languages goes further. It explicitly recommends that only | the markup be used. | | [snip] | | RLM and LRM characters | | Two other invisible but non-embedding directional control characters | provided by Unicode do not usually have corresponding markup and should | be used either in character or escaped form. Note that they are less | problematic because they are used singly, not in pairs to delimit ranges | of text like the other control characters we have discussed. | | U+200E: LEFT-TO-RIGHT MARK | U+200F: RIGHT-TO-LEFT MARK `---- >> Currently, in Org-mode, one cannot have multi-paragraph tables. >> Assuming that in near future, it does support such tables, how would one >> go about fixing the directionality. > > You already asked this in the past, and I already provided several > alternatives. One is to use TAB characters, another is to use the > '(space . PROPS)' display spec, yet another is to use RLM/RLM > controls. Between these, I don't believe there's a problem we won't > be able to solve. I am sleeping on it. The scenario I am placing is this: Org-mode table + Multi-paragraph table cells + Mixed scripts. >From the FAQ above, ,---- | ... Using Unicode controls results in a lot more work to achieve the | same result. Also it is difficult to know how to achieve effects like | reversing table columns and right-aligning text with just Unicode | control codes. `----