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 20:48:25 +0300 Message-ID: <83mxdvqhee.fsf@gnu.org> References: <87obybg01n.fsf@gmail.com> <87hb43fsq0.fsf@gmail.com> <83zkhvr07u.fsf@gnu.org> <631B4E70034844D78E123FF1527968C2@us.oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1316800068 1853 80.91.229.12 (23 Sep 2011 17:47:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 23 Sep 2011 17:47:48 +0000 (UTC) Cc: 9571@debbugs.gnu.org, lekktu@gmail.com, stepnem@gmail.com To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 23 19:47:43 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 1R79qg-000218-JX for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 19:47:42 +0200 Original-Received: from localhost ([::1]:59780 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R79qg-0008PJ-7E for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 13:47:42 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:35059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R79qc-0008Ks-9d for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 13:47:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R79qZ-0005t7-VY for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 13:47:38 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43104) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R79qZ-0005sw-Tn for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 13:47:35 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R79r1-0002cK-0L for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 13:48:03 -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 17:48: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.131680008210055 (code B ref 9571); Fri, 23 Sep 2011 17:48:02 +0000 Original-Received: (at 9571) by debbugs.gnu.org; 23 Sep 2011 17:48:02 +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 1R79qy-0002c0-7P for submit@debbugs.gnu.org; Fri, 23 Sep 2011 13:48:01 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R79qu-0002bq-U2 for 9571@debbugs.gnu.org; Fri, 23 Sep 2011 13:47:58 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LRZ00L00L94JS00@a-mtaout20.012.net.il> for 9571@debbugs.gnu.org; Fri, 23 Sep 2011 20:47:25 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.8.215]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LRZ00LG4LEZJW80@a-mtaout20.012.net.il>; Fri, 23 Sep 2011 20:47:25 +0300 (IDT) In-reply-to: <631B4E70034844D78E123FF1527968C2@us.oracle.com> 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 13:48:03 -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:51730 Archived-At: > From: "Drew Adams" > Cc: <9571@debbugs.gnu.org>, > Date: Fri, 23 Sep 2011 09:09:56 -0700 > > sn> OOH, there was a time when suggesting that the user adds > sn> something to .emacs, like (setq-default bidi-display-reordering nil) > sn> was not considered obscure. Not everything must go through the > sn> customization interface. > > First, we have _not_ suggested that to users. Because it's _not_ a user variable. The fact that it's documented in the user manual is already more than we normally would do about such toggles. > Currently, users need to figure out for themselves that the variable exists, > what it does, and that it is buffer-local. And they need to learn about > buffer-local variables and `setq-default'. No, they aren't required to. They should report any abnormal behavior as bugs. > It seems clear that you, Eli, are resisting making it obvious how to turn off > this feature you implemented. Is ego mixed in there a bit, perhaps? I cannot be a shrink to myself; maybe it is. If so, it would only be human. I could ask you the same question. Neither will get us anywhere nearer to an agreement. Just drop it. > But that does not mean that we should not make it very clear to users how they > can easily turn it off. Let me be very clear: there is no way for users to turn this off. There's an internal variable that bypasses most of the bidi-aware code. That variable exists for 2 purposes only: (a) let interested individuals, such as myself, see if some problem could be due to the bidi-aware parts of the display engine, and (b) allow Lisp code to turn off bidi reordering where it is needed. I don't mind you or others take advantage of this variable if they so prefer. But please understand that making a user option to force Emacs use Emacs 23 vintage display code will need much more work than just adding a defcustom, because that code was extensively modified as part of development of the bidi-aware display. IOW, when you set bidi-display-reordering to nil, all bets are off regarding the correctness of the display operation, because I do that only very rarely (lately almost never), and only for specific debugging purposes. I cannot in good faith recommend that users use this mode because I don't use it enough to vouch for its correctness and its being free of bugs. You are on your own when you use this mode. Bugs reported for Emacs 24 when this variable is nil will go to the bottom of my todo list. So by pressing for this user option you actually do them a disservice. I realize that you do that because you are not aware of the extent of changes done to the Emacs 23 display code. That's why I say this: now you do know. > We already have a way for users to turn bidi off, and that's good. No, we don't. What you call "bidi" cannot be turned off, not entirely. For example, there's no way to turn off reordering of the mode line and header line, without switching off the reordering entirely. Likewise for the tool bar. It is unthinkable for user-friendly settings to behave like that. > But the proper test is not whether using `setq-default' for this is good enough > for you or this or that Emacs-Lisp aficionado. Users should be able to turn > bidi off using Customize, IMO. This is a _user_ setting. It is a _user's_ choice > whether to turn bidi support off. But it is _not_ a user setting. It was never meant to be, and the code was neither designed nor implemented with such an option in mind. It's not just a missing defcustom, much more is missing to make Emacs display dual-mode like what you seem to think. IOW, your mental model of this variable and its effects is profoundly wrong. > ez> ??? The variable and its effect are clearly documented in both the > ez> user manual and the ELisp manual. > > Documented, yes, but not clearly. You do not state clearly that to turn off bidi > support in a given buffer you need to set the variable to nil, and to turn it > off generally you need to `setq-default' it to nil. Because it's not a user option. Variables that are not user options are normally not documented at all in the user manual. I went out of my way in this matter. More information about this (including the effect of setq-default for this variable) can be found in the ELisp manual, and I wrote it there because I consider that manual to be important for Emacs maintainers, not just for ELisp programmers. > If optionhood is good enough for `bidi-paragraph-direction' then it is good > enough for `bidi-display-reordering' too. The paragraph direction is (and must be) a user setting. Only a human can know better than Emacs what is the correct base direction of the paragraphs in a document. Other bidi-aware programs all have equivalent knobs. But no other application I know of has an option to turn off bidi reordering. They either do it always or not at all. That's how Emacs's bidi display was designed, too. You are asking for something that is not in the design. > rms> It has to be easy to do, so why NOT do it? > ez> > ez> Because the unidirectional display will one day go away, and having a > ez> user option will be an obstacle to getting rid of it. > > When it does go away, so will the option to disable it. The fact that it might > one day go away is no reason not to have an option NOW to disable it. That is a naive and unrealistic view of software maintenance. Users who will customize this option on their .emacs file will object to the change, and rightfully so. The result will be slow and painful process that will take years. We have been there more than once. For once, I'd like to try doing this The Right Way, where things depend on me. Maybe it's a lost battle, but I'd like to try fighting it anyway.