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 22:55:57 +0900 Message-ID: <87ipqdgu1e.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> <87k4ath4rd.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 1312466172 9961 80.91.229.12 (4 Aug 2011 13:56:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 4 Aug 2011 13:56:12 +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 15:56:06 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 1QoyP7-0000q5-TE for ged-emacs-devel@m.gmane.org; Thu, 04 Aug 2011 15:56:06 +0200 Original-Received: from localhost ([::1]:35086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoyP7-00052Y-Du for ged-emacs-devel@m.gmane.org; Thu, 04 Aug 2011 09:56:05 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoyP1-00051S-Eq for emacs-devel@gnu.org; Thu, 04 Aug 2011 09:56:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoyOx-0008V5-BP for emacs-devel@gnu.org; Thu, 04 Aug 2011 09:55:59 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:41836) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoyOu-0008U2-V7; Thu, 04 Aug 2011 09:55:53 -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 81C103FA06F9; Thu, 4 Aug 2011 22:55:49 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id F17411A26F8; Thu, 4 Aug 2011 22:55:57 +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:142865 Archived-At: 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. Applications should be robust to that, and I'm not terribly sympathetic to ones that aren't. I do grant that it will often be what the user wants, especially Emacs users, since Emacs can provide a byte-level view of the file if the user wants that. On the other hand, I see no reason why a text-property-based implementation should be lossy. Handling that kind of thing is done all the time in serialization functions. 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? > 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. Yes, that is you. But you're right, you have something that works for you, more, you have no reason to believe that there's any crippling bug in the design so it "should" work for most people who need it, and it's time to get it out the door.