From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Welsh Duggan Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Thu, 04 Aug 2011 23:41:27 -0400 Message-ID: <87r550msns.fsf@maru.md5i.com> References: <20110731.082721.451360942.wl@gnu.org> <20110731.085115.40009301.wl@gnu.org> <877h6yanje.fsf@fencepost.gnu.org> <878vre95g3.fsf@fencepost.gnu.org> <87fwlm7fam.fsf@fencepost.gnu.org> <87bowa7dza.fsf@fencepost.gnu.org> <877h6y7chn.fsf@fencepost.gnu.org> <831ux6cv5o.fsf@gnu.org> <87d3gpku3o.fsf@gnus.org> <834o1ypa2b.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1312515722 11273 80.91.229.12 (5 Aug 2011 03:42:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 5 Aug 2011 03:42:02 +0000 (UTC) Cc: Lars Magne Ingebrigtsen , list-general@mohsen.1.banan.byname.net, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 05 05:41:58 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 1QpBIL-0003tZ-ND for ged-emacs-devel@m.gmane.org; Fri, 05 Aug 2011 05:41:57 +0200 Original-Received: from localhost ([::1]:57244 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpBIL-0008Nf-AV for ged-emacs-devel@m.gmane.org; Thu, 04 Aug 2011 23:41:57 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:36803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpBIJ-0008NU-0B for emacs-devel@gnu.org; Thu, 04 Aug 2011 23:41:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QpBIH-0005dq-U4 for emacs-devel@gnu.org; Thu, 04 Aug 2011 23:41:54 -0400 Original-Received: from md5i.com ([75.151.244.229]:55091 helo=maru.md5i.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpBIG-0005ch-65; Thu, 04 Aug 2011 23:41:52 -0400 Original-Received: from md5i by maru.md5i.com with local (Exim 4.76) (envelope-from ) id 1QpBHr-00045W-7V; Thu, 04 Aug 2011 23:41:27 -0400 In-Reply-To: <834o1ypa2b.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 Aug 2011 22:30:20 +0300") User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 75.151.244.229 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:142894 Archived-At: Eli Zaretskii writes: > You are wrong. LRM, RLM, etc. exist _precisely_ for these purposes: > to arrange bidirectional text for display as the display designer > wishes, where the implicit reordering mandated by the UBA does not > give satisfactory results. These _explicit_ directional control > characters exist for when the _implicit_ reordering fails. It's the > functional equivalent of the corresponding HTML directives -- you > won't say that HTML is "suboptimal" when it dictates to the browser > how to render bidirectional text, would you? [...] > This issue was discussed at length long ago, when the basic design of > bidi support for Emacs was on the table. Text properties were > suggested almost immediately, then rejected after prolonged debates, > because they simply aren't up to this job, and because the Unicode > Standard already tells us how to DTRT, we just need to heed. I have no issue with using directional control characters in the buffer to handle alignment issues, etc. I do have the following questions, though, and am looking for suggestions for how they should be implemented. Scenario: Say we are desirous of updating XML mode to protect the neutral characters that make up tags so they don't end up in visually confusing locations. This can be done by adding proper directional codes in the right locations. However, we would need to solve the following two questions: 1) We need to strip these directional characters (but not other ones in the data sections of the XML) when saving the files. 2) We don't really want cursor movement to stop on each of these directional characters. They are there to make display look correct, but are not part of the data stream that the user is editing. 3) When doing search, people are not going to want to have to add the directional codes to their search strings in order to, say, search for a tag next to some text. These formatting characters need to be "invisible" with respect to isearch and friends. 4) Not as important, but in this case we would want the formatting characters we add in order to make markup display appropriately to be non-visible, whereas formatting characters in the user text, we might want displayed using thin-space or as a boxed character. How should these problems be solved? Or what feature(s) should be added to allow this to be implemented? -- Michael Welsh Duggan (md5i@md5i.com)