From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Thu, 04 Aug 2011 19:04:22 +0900 Message-ID: <87k4ath4rd.fsf@uwakimon.sk.tsukuba.ac.jp> 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> <87sjphhnbj.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1312452274 18514 80.91.229.12 (4 Aug 2011 10:04:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 4 Aug 2011 10:04:34 +0000 (UTC) Cc: larsi@gnus.org, 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 Thu Aug 04 12:04:29 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 1Qoumy-0005nM-N9 for ged-emacs-devel@m.gmane.org; Thu, 04 Aug 2011 12:04:28 +0200 Original-Received: from localhost ([::1]:37802 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qoumy-00085G-2r for ged-emacs-devel@m.gmane.org; Thu, 04 Aug 2011 06:04:28 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:53462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qoumv-00084z-CA for emacs-devel@gnu.org; Thu, 04 Aug 2011 06:04:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qoumu-00049j-Gh for emacs-devel@gnu.org; Thu, 04 Aug 2011 06:04:25 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:40519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qoums-00048K-Ji; Thu, 04 Aug 2011 06:04:23 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 03C3D3FA06DE; Thu, 4 Aug 2011 19:04:14 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6D9561A26F8; Thu, 4 Aug 2011 19:04:22 +0900 (JST) In-Reply-To: X-Mailer: VM 8.1.93a under 21.5 (beta31) "ginger" cd1f8c4e81cd XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 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:142862 Archived-At: Eli Zaretskii writes: > Yes, but we are not talking about the internal handling. Of course we are. Whether explicit directionality is represented in the buffer as directional marks or as a text property is a purely internal matter. > Nor is it specific to text external to Emacs: after all, the > internal storage of text in Emacs, as in many other applications, > is just a linear byte stream. That's just saying that you *can* use directional marks for this purpose. It is not a reason you *should*. > Such unexpected conversions behind user's back proved to be an > annoyance, as the experience of MULE shows. With all due respect to Handa-san and the other MULE implementers, MULE was implemented to be too smart for its own good. This is a good idea for Japanese text, where at this very second I can lay my hands on files containing no less than 5 major very different encodings of Japanese (not to mention at least 5 more minor corporate variations, plus Japanese written in scripts meant for Chinese). It was not such a great idea for other environments, although it mostly doesn't hurt too much. I would not extrapolate from the MULE experience to designs that could be a lot more precise and explicit. > . since each character can have only one value of the direction > property, you cannot do this in any simple way; you'd need to > split the original region in 3 parts, which is ugly It's no uglier than inserting control sequences, which means that text has yet another feature that prevents it from being an array of characters. > and complicates what needs to be done when text in this region > is deleted (keep in mind that the UBA mandates support of up to > 60 levels of such embedded direction reversals, don't ask me > why, and Emacs is in full compliance) > > > If for some subtle reason, they don't quite nest correctly for this > > purpose, overlays most likely will. > > Overlays don't get copied with the text, so if you copy/paste text > into another area of the same buffer or into another buffer, the nice > display will be lost. Ah. I see. I forgot about that "feature" of the implementation in Emacs. > We could complicate the heck out of yanking so it reinserts the > overlays, of course, but why complicate things if an easier way is > available that is straightforward? Because it's correct, mostly. You have convinced me that it would be quite inconvenient to implement these things in Emacs without introducing XEmacs-like extents that can have some of the properties of both text properties and overlays. I'm still not convinced that the problems Lars worries about won't annoy the users. > The question that bugged us during the early stages of the design > was how do you ensure this without asking Lisp application > programmers to jump through the hoops every time text is copied or > saved or read. It turns out that using the directional control > characters is the easiest way. That's reasonable. > If we drop the marks on yanking, text will look differently when > yanked, sometimes completely differently, to the degree of being > incomprehensible. Obviously. Nevertheless, I suspect there will be applications where that is desirable (especially for marks at the boundary of the yanked region).