From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Thu, 04 Aug 2011 06:36:06 -0400 Message-ID: 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> <87k4ath4rd.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1312454185 30217 80.91.229.12 (4 Aug 2011 10:36:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 4 Aug 2011 10:36:25 +0000 (UTC) Cc: larsi@gnus.org, list-general@mohsen.1.banan.byname.net, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 04 12:36:20 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 1QovHn-0003vi-I2 for ged-emacs-devel@m.gmane.org; Thu, 04 Aug 2011 12:36:20 +0200 Original-Received: from localhost ([::1]:50392 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QovHn-0003O6-5i for ged-emacs-devel@m.gmane.org; Thu, 04 Aug 2011 06:36:19 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QovHi-0003Np-Hi for emacs-devel@gnu.org; Thu, 04 Aug 2011 06:36:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QovHe-00034N-K1 for emacs-devel@gnu.org; Thu, 04 Aug 2011 06:36:14 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:49824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QovHe-00034I-HG for emacs-devel@gnu.org; Thu, 04 Aug 2011 06:36:10 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QovHa-00089N-To; Thu, 04 Aug 2011 06:36:07 -0400 In-reply-to: <87k4ath4rd.fsf@uwakimon.sk.tsukuba.ac.jp> (stephen@xemacs.org) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:142864 Archived-At: > From: "Stephen J. Turnbull" > Cc: larsi@gnus.org, > list-general@mohsen.1.banan.byname.net, > emacs-devel@gnu.org > Date: Thu, 04 Aug 2011 19:04:22 +0900 > > > 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*. Directional marks need to be supported anyway, if we want to be compliant. Using that for "fixing" specially-formatted text as well gives us 2 features for the cost of one. > I would not extrapolate from the MULE experience to designs that could > be a lot more precise and explicit. Precisely and explicitly, I think that using lossy conversions is not a good idea, if there are practical alternatives. Just visiting a file, then saving it without changes should produce the a byte stream that is identical to the original one. I hope you agree with that. > > . 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 I mean ugly on the implementation level. This splitting (and the corresponding joining) need to be implemented, or else each Lisp program would need to do it by hand. By contrast, inserting a character does not need any additional features. Text in mail summary buffers is already formatted specially, by inserting separators between fields; adding one more character to the field separator is not fundamentally different. > which means that text has yet another feature that prevents it from > being an array of characters. ??? LRM is just another character, like SPC or `|'. The text is still an array of characters after inserting it. > I'm still not convinced that the problems Lars worries about won't > annoy the users. I'm not convinced either. But "the proof of the pudding is in eating." These questions are around since 12 years ago, and no one ever had the definitive answers. If I'd to wait for such answers, Emacs wouldn't have bidi support it has now. So I made some decisions (and published them here almost 2 years ago, btw), and implemented them. Having used them for some time, I can say that they are quite satisfactory, but that's me. Let's get Emacs 24.1 out the door, using the existing functionality, and let the users of R2L scripts at large judge. This discussion, however useful and enlightening, cannot be a substitute for user experience, especially since most of the participants don't use R2L scripts. > > 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). I don't see why, but it isn't worth arguing, since removing them is easy.