From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#9571: 24.0.50; user option to turn off bidi, please Date: Fri, 23 Sep 2011 23:09:49 +0300 Message-ID: <83d3erqauq.fsf@gnu.org> References: <83sjnnqpts.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1316808585 27370 80.91.229.12 (23 Sep 2011 20:09:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 23 Sep 2011 20:09:45 +0000 (UTC) Cc: 9571@debbugs.gnu.org To: rms@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 23 22:09:41 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1R7C44-0004Ym-9O for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 22:09:40 +0200 Original-Received: from localhost ([::1]:39918 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7C43-00066M-92 for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 16:09:39 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:34765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7C40-000666-5N for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 16:09:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R7C3y-0006fW-NL for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 16:09:36 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33308) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7C3y-0006fS-IL for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 16:09:34 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R7C4Q-0006fe-38 for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 16:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 23 Sep 2011 20:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9571 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 9571-submit@debbugs.gnu.org id=B9571.131680854625574 (code B ref 9571); Fri, 23 Sep 2011 20:10:02 +0000 Original-Received: (at 9571) by debbugs.gnu.org; 23 Sep 2011 20:09:06 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R7C3V-0006eR-MR for submit@debbugs.gnu.org; Fri, 23 Sep 2011 16:09:05 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R7C3R-0006dz-Le for 9571@debbugs.gnu.org; Fri, 23 Sep 2011 16:09:03 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LRZ00G00RKL5E00@a-mtaout22.012.net.il> for 9571@debbugs.gnu.org; Fri, 23 Sep 2011 23:08:26 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.8.215]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LRZ00G5FRY14PW0@a-mtaout22.012.net.il>; Fri, 23 Sep 2011 23:08:26 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 23 Sep 2011 16:10:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:51741 Archived-At: > Date: Fri, 23 Sep 2011 15:44:34 -0400 > From: Richard Stallman > CC: monnier@iro.umontreal.ca, 9571@debbugs.gnu.org > > What confusion are you referring to? > > Not being sure about the order, in the buffer, of the characters you see > on the screen. If you need to see the buffer order, moving with C-f and C-b will show you the order in the buffer, because cursor motion still works in buffer order. > Are we talking about a buffer > with or without R2L characters? > > It would have to be a case where characters that have bidi > significance are present. If the reordering is correct, there could be no confusion, because the text is then legible. If it is illegible, then there's a bug that needs to be reported. For example, if there are no R2L characters in the text, the result of reordering should be identical to not reordering at all. Any person who can read whatever language we are talking about will instantly distinguish between correct and incorrect order. I see no place for any confusion here. Users will gain nothing from this option, because turning off reordering when R2L text is involved does not make the text more legible; quite the opposite. I explained in my other messages what will users lose if they have such an option, unless someone invests a non-trivial amount of work to restore the old code where I deleted or rewrote it, and maintain that code as a separate execution branch for years to come. > If there are [no R2L characters], there is no > reordering, thus no possibility it can cause confusion. You are wrong: _all_ characters are displayed in Emacs 24 via the reordering engine. It's just that plain left-to-right text emerges from that reordering in its original buffer order. But the reordering engine doesn't "know" that, it just implements the rules of reordering. > And how would setting > bidi-display-reordering to nil resolve that confusion? > > You would see all the characters in the order that they > appear in the buffer. That will not resolve any confusion. As someone who happened to read R2L text in Emacs 23 (e.g., in email messages), I can assure you: seeing R2L text in buffer order confuses even more than seeing results of slightly incorrect reordering. It makes the reading process very slow and error prone, even if your command of the language is very good. > I don't envision anyone would want to edit this way. But it could be > useful to look at this kind of display once in a while. It's not useful for users, believe me. It could be useful to someone who debugs Emacs display, but there's no need for user option for that use case. > Because the unidirectional display will one day go away, and having a > user option will be an obstacle to getting rid of it. > > Why should it ever be deleted? What is gained by deleting it? Easier maintenance. Emacs display engine is already more complex that humanly perceptible. Having two divergent engines in one means unnecessarily complicating maintenance and slowing down development, because every change needs to be tested twice and every new feature needs to be designed so it works in both modes. I'm quite sure doing this will be a waste of resources which are already at premium. There's no need for the old unidirectional display code; as I explained above, straight left-to-right text is treated by the bidirectional code correctly and transparently to the users.