From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#9571: 24.0.50; user option to turn off bidi, please Date: Fri, 23 Sep 2011 09:09:56 -0700 Message-ID: <631B4E70034844D78E123FF1527968C2@us.oracle.com> References: <87obybg01n.fsf@gmail.com><87hb43fsq0.fsf@gmail.com> <83zkhvr07u.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1316794245 25302 80.91.229.12 (23 Sep 2011 16:10:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 23 Sep 2011 16:10:45 +0000 (UTC) Cc: 9571@debbugs.gnu.org, lekktu@gmail.com To: "'Eli Zaretskii'" , "=?UTF-8?Q?'=C5=A0tep=C3=A1n?= Nemec'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 23 18:10: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 1R78Km-00034Z-U6 for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 18:10:41 +0200 Original-Received: from localhost ([::1]:38699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R78Km-0006CL-8i for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 12:10:40 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R78Ki-0006Bt-8f for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 12:10:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R78Kg-0004LN-Ok for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 12:10:36 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R78Kg-0004LJ-N5 for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 12:10:34 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R78L7-0000Nd-Ku for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 12:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 23 Sep 2011 16:11:01 +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.13167942541447 (code B ref 9571); Fri, 23 Sep 2011 16:11:01 +0000 Original-Received: (at 9571) by debbugs.gnu.org; 23 Sep 2011 16:10:54 +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 1R78Kz-0000NI-HA for submit@debbugs.gnu.org; Fri, 23 Sep 2011 12:10:53 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R78Kj-0000Mx-Mw for 9571@debbugs.gnu.org; Fri, 23 Sep 2011 12:10:52 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8NGA7CY017242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 16:10:09 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8NGA637003003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 16:10:07 GMT Original-Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8NGA1qK017892; Fri, 23 Sep 2011 11:10:01 -0500 Original-Received: from dradamslap1 (/10.159.48.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 09:10:00 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acx54FTYEJz/AHWgSt6ZtbHUHgILdgAJEvcQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 In-Reply-To: <83zkhvr07u.fsf@gnu.org> X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4E7CAF61.01D4:SCFMA922111,ss=1,re=-4.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 23 Sep 2011 12:11:01 -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:51723 Archived-At: 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. To suggest that would be a good first step. 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, not every user is up on this stuff. It will not be obvious to all users how they might turn off bidiness. _That is the point of this bug report_: give users an option and document it clearly as turning off bidi. Make it obvious to users. 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? Let me be clear (again). Bidi support is a _good_ thing. I was the first to respond to your announcement of it, saying "Great!". And I admire your work on it as a real accomplishment. But that does not mean that we should not make it very clear to users how they can easily turn it off. For some reason, this seems to be an emotionally charged issue for some people. When I first suggested, in emacs-devel, giving users an easy way to turn it off, I was practically accused (not by you, Eli) of western imperialism, l2r-ism and nasty asciiness. Nothing could be further from the truth. I'm 100% in favor of Emacs supporting bidirectional text. We already have a way for users to turn bidi off, and that's good. I just want to see it as (a) a user option and (b) clearly advertised (documented). sn> It's certainly good enough to me, but you won't find that sn> advice in the current documentation either, AFAICT. Correct. Adding it to the doc would be a good first step. 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. 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. As Stepan (sorry about the ASCII/misspelling) replied to you: sn> (it says the variable "controls whether text in the buffer is reordered for display"; sn> is a user with no clue about bidi likely to understand that as "when set sn> to nil, the text in the buffer should behave just as before the bidi sn> feature was introduced"? I don't know, but I suspect I might not, if I sn> hadn't seen previous comments and references to the variable and its sn> effects on emacs-devel and other places). ez> Which is more than I can say for ez> the other new features introduced in Emacs 24, because documentation I agree with Eli about that last sentence, and I applaud his long and continuing interest in and efforts for the doc - second perhaps only to Richard's. The bidi stuff is much more, and presumably better, documented than other Emacs 24 changes, so far. A good case in point is the (apparently still volatile) buffer-display stuff. ez> What else besides documentation of the variable is needed to make it ez> clear to users how to turn a feature off? 1. Clearer doc about turning it off, as Stepan pointed out (above). 2. A user option, findable by looking for _options_, e.g. `apropos-variable bidi' (without C-u). If optionhood is good enough for `bidi-paragraph-direction' then it is good enough for `bidi-display-reordering' too. A user trying `apropos-variable bidi', looking for how to turn bidi off, should find the answer easily. sn> Also, this is not (only) about making `bidi-display-reordering' a custom variable. My bug report _is_ only about providing a user option for this. 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.