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 10:53:54 -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> <87ipqdgu1e.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1312469656 1904 80.91.229.12 (4 Aug 2011 14:54:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 4 Aug 2011 14:54:16 +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 16:54:08 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 1QozJI-0002J4-Cy for ged-emacs-devel@m.gmane.org; Thu, 04 Aug 2011 16:54:08 +0200 Original-Received: from localhost ([::1]:53300 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QozJH-0002c2-Sh for ged-emacs-devel@m.gmane.org; Thu, 04 Aug 2011 10:54:07 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QozJB-0002Z7-P9 for emacs-devel@gnu.org; Thu, 04 Aug 2011 10:54:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QozJ7-00043p-D6 for emacs-devel@gnu.org; Thu, 04 Aug 2011 10:54:01 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:40903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QozJ7-00043k-BS for emacs-devel@gnu.org; Thu, 04 Aug 2011 10:53:57 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QozJ4-0002tT-Ju; Thu, 04 Aug 2011 10:53:54 -0400 In-reply-to: <87ipqdgu1e.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:142872 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 22:55:57 +0900 > > Eli Zaretskii writes: > > > 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. > > I don't. Not in the context of Unicode. It should produce a sequence > of characters identical to the original one. However, the user may > have excellent reasons for doing, say, normalization, and therefore > the sequence of bytes may be different. Normalization is not relevant to directional control characters. Let's stick to the issue at hand: do you consider it a good idea to remove or add these characters in an otherwise unmodified buffer? > I see no reason why a text-property-based implementation should be > lossy. Because the user could type directional controls, and there's no way for Emacs to know at all levels which one is to be treated in which way. > Regarding handling the splitting and joining of regions: > > > I mean ugly on the implementation level. This splitting (and the > > corresponding joining) need to be implemented, > > I don't understand. If `put-text-property' and friends don't get that > right already, more than bidi is in trouble, I should think. What's > special about bidi? What is special is the fact that bidi needs nested regions with different values for the same property. Normally, if you put a property with a value on a portion of text that has another value for that property, the new value replaces the old one.