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 17:32:08 -0700 Message-ID: <249B07D27CD640E69D493B6FC05CD73E@us.oracle.com> References: <87obybg01n.fsf@gmail.com> <87hb43fsq0.fsf@gmail.com> <83zkhvr07u.fsf@gnu.org> <631B4E70034844D78E123FF1527968C2@us.oracle.com> <83mxdvqhee.fsf@gnu.org> <42AFDF737DB84A93858CA84ABA91A84D@us.oracle.com> <83fwjnqbxs.fsf@gnu.org> <1EB39F8E0391465CB3F1803054CAF35D@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1316824364 23213 80.91.229.12 (24 Sep 2011 00:32:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 24 Sep 2011 00:32:44 +0000 (UTC) Cc: 9571@debbugs.gnu.org, stepnem@gmail.com To: "'Juanma Barranquero'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 24 02:32:40 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 1R7GAZ-00082Z-8f for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Sep 2011 02:32:39 +0200 Original-Received: from localhost ([::1]:33842 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7GAY-0006vn-LP for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 20:32:38 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:40394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7GAV-0006ve-42 for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 20:32:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R7GAT-0007xK-Me for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 20:32:35 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7GAT-0007xG-IX for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 20:32:33 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R7GAw-00050X-6e for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 20:33:02 -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: Sat, 24 Sep 2011 00:33: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.131682437319233 (code B ref 9571); Sat, 24 Sep 2011 00:33:02 +0000 Original-Received: (at 9571) by debbugs.gnu.org; 24 Sep 2011 00:32:53 +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 1R7GAn-000509-A3 for submit@debbugs.gnu.org; Fri, 23 Sep 2011 20:32:53 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R7GAk-000501-3C for 9571@debbugs.gnu.org; Fri, 23 Sep 2011 20:32:51 -0400 Original-Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8O0WI0r015771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Sep 2011 00:32:20 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8O0WGY7003225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Sep 2011 00:32:17 GMT Original-Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8O0WB5W024750; Fri, 23 Sep 2011 19:32:11 -0500 Original-Received: from dradamslap1 (/10.159.48.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 17:32:10 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acx6R7QdMhHTSdY/T06zXcHwcZBfKwAAIKqg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 In-Reply-To: X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090206.4E7D2514.0087,ss=1,re=0.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 23 Sep 2011 20:33: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:51750 Archived-At: > And that is the case here: the number of people who understands both > the Emacs display engine and the issues related to bidi can be counted > with a couple bits, and I'm being generous. So if Eli says that he's > not going to devote time to some issue related to it, it's not > unrealistic to expect that it won't happen (soonish). I think everyone realizes that. This bug report is about making the = variable into a user option. As Eli has said, we don't need his valuable time = and expertise for that. > Your insistence in keeping the issue as a wishlist I mentioned "wishlist" only after Eli himself indicated that it needs = more work "if we can find someone to invest that work". I don't think this bug report - which asks for a user option, should be = closed, or classified wontfix (already done), or sent to the wishlist. I think we should make the var an option now AND (based on what Eli has = said) add an enhancement request to the wishlist for more development to = support the nil value - whether or not Eli is the only one on the planet who could = ever hope to respond to such a wish. If you exclude things from the wishlist just because there is no one = around today who has the time to work on them, then it is not a wishlist. > is just the hope that someone will someday want to change > the display engine to suit your preferences. No, you haven't been reading what I said. It's not about my = preferences. I truly have no idea whether I will want this thing on or off, = personally, as I indicated clearly several times. As I said, if there seems to be no = downside, I will likely just leave it on. That's even though I do not expect to have any need for bidirectional = editing. Why then? To closer reflect what others use, including people who might = use some of my code. As you know, each departure from emacs -Q makes bug = reporting just that much harder. But again, I have no idea now what I will do, and this bug report has = NOTHING to do with my (nonexistent) preferences wrt the variable value. > > Limbo is apparently no more >=20 > Not exactly, no. In fact, the official position of the Catholic Church > has not changed, news reports notwithstanding. > http://en.wikipedia.org/wiki/Limbo#Modern_era Thinking, in fact, of you, Juanma, I read precisely that Wikipedia = article BEFORE I wrote that sentence, being personally ignorant and indifferent = to limbosity. And that is _exactly_ why I added "(and perhaps never was)" immediately following the words you quoted (but which you chose to cut). That article makes it clear that the situation wrt the Catholic Church = is less than clear wrt "limbo" - even after P.B. XVI's 2007 publication, and = that there have been multiple notions of "limbo" over the ages, etc. "And perhaps never was" sums up the situation quite accurately, as I = read that Wikipedia article. Not that I really care... > > So far, it seems (but I can't speak for him, obviously)=20 > > that Richard is not convinced either. =A0He has repeated the > > same thing as I: why shouldn't this be a user option? >=20 > Because the option it would currently offer is bogus. Then so is the same variable as a NON-option bogus. And then so is its treatment in two (count 'em!) Emacs manuals. I didn't create that = variable, nor did I describe it in the manuals. You cannot have it both ways. Either this is something useful for users = to know about or it is not. If it is, then AFAICT it is just as useful for = non-Lispers as for Lispers, for those who understand `setq-default' and buffer-local = vars as well as for those who do not. > > Emacs has been about partial control, better-than-nothing, and > > do-the-best-we-can, since its inception. =A0Above all, it has=20 > > been about giving users as much control as possible. >=20 > It has also been about using resources (=3D developers) in the most > efficient way possible. There are two different issues that have been discussed here: 1. Make the variable into an option, and tell users more clearly about = what nil does. 2. Work more on the code to be able to more solidly "support" the nil = use case. This bug report asked only for #1. As Eli has admitted, it doesn't take = much in the way of resources to do that. It is Eli, not I, who brought up #2 = and pointed to potential problems if users set the variable to nil. And let's not be under any illusions about this "support". Not making = it a user option does not let Emacs "support" off the hook. The existence of the variable, and especially its description in both Emacs manuals, means = that some users will likely set it to nil. > > It's about giving users the knowledge and access, even if=20 > > the results of using nil are not 100% predictable or 100% good. >=20 > Are there really that many users that will want to disable > bidi-display-reordering, Who knows? Do you? > knowing that the result will likely be buggier than the > default? But how on Earth will they know that? Saying anything about that in the = doc was specifically verboten by Eli: Saying in the manual that some feature "means trouble" is not something we use [sic] to do, because users will say "if it's trouble, why don't you fix it?". > And if they do exist, do they really need a defcustom? To quote a famous person, why not? "Why are you opposed to a flag to = turn bidi display off?" Why should you, Juama, who are familiar enough with buffer-local vars = etc. to understand how to turn this off (if you wanted to), be able to do so; = but not Jane Doe, who understans how to use Customize but knows nothing about `setq-default'? Do you "really need" to keep this optional behavior to yourself and = others with Emacs-Lisp knowledge? > > I would prefer that we offer a user option. =A0Not for me,=20 > > but for others, who might not be so clear about Lisp, > > buffer-local variables, and `setq-default'. >=20 > A defcustom is an statement that something is a switch, and both modes > are reasonable. That is not the case here. No more so than for any other variable. Nothing is guaranteed in Emacs. = User options no more than other vars. You are making a mountain out of a = mole hill. > > No one is asking that you document the implementation. =A0 > > Think in terms of what might help a user who does happen > > to set the variable to nil. =A0That's the kind > > of info that it could be helpful to add to the manual. =A0 > > Nothing more. >=20 > Your defcustom request can be trivially satisfied, and not a word is > needed in the manual: >=20 > (defcustom bidi-display-reordering t > "Not a user option. Do NOT set it to nil. Horrible things will > happen. Thanks." :type 'boolean :version "24.1" You forgot a paren.) But I could actually live with that, provided the = manual still describes the variable fairly, as it does now (and hopefully a bit = more clearly wrt what nil does). I wouldn't choose such a doc string myself, but if that's the price to = pay for giving users an option they can find easily using `apropos-variable' = then it might be worth it.=20 But I don't think you'll convince Eli to use such language - see above.