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 14:23:47 -0700 Message-ID: <1EB39F8E0391465CB3F1803054CAF35D@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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1316813086 24674 80.91.229.12 (23 Sep 2011 21:24:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 23 Sep 2011 21:24:46 +0000 (UTC) Cc: 9571@debbugs.gnu.org, lekktu@gmail.com, stepnem@gmail.com To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 23 23:24: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 1R7DEd-0005Vp-Fn for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 23:24:39 +0200 Original-Received: from localhost ([::1]:55429 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7DEc-0003ai-UO for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 17:24:38 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7DEZ-0003aS-3S for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 17:24:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R7DEX-0002kP-Ls for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 17:24:35 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41621) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7DEX-0002kL-It for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 17:24:33 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R7DEz-0008Pq-MD for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 17:25: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 21:25: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.131681308132321 (code B ref 9571); Fri, 23 Sep 2011 21:25:01 +0000 Original-Received: (at 9571) by debbugs.gnu.org; 23 Sep 2011 21:24:41 +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 1R7DEe-0008PG-N9 for submit@debbugs.gnu.org; Fri, 23 Sep 2011 17:24:41 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R7DEc-0008P7-0L for 9571@debbugs.gnu.org; Fri, 23 Sep 2011 17:24:39 -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 p8NLNw9n012133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 21:24:00 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8NLNuM4025335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 21:23:57 GMT Original-Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8NLNovU015226; Fri, 23 Sep 2011 16:23:50 -0500 Original-Received: from dradamslap1 (/10.159.48.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Sep 2011 14:23:50 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acx6KU/rg8NodsbQS4qL+D0hT1m5kwAA8Mig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 In-Reply-To: <83fwjnqbxs.fsf@gnu.org> X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090205.4E7CF8F7.0069,ss=1,re=-2.300,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 23 Sep 2011 17:25: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:51744 Archived-At: > > > 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. > > > > How is that different from turning it off, from a user perspective? > > _Parts_of_it_ can be turned off. What you get is part bidi and part > not. What that does is anyone's guess. Anyone's guess, unless someone checks and specifies what it does. And why is it that that won't happen? > > > 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. > > > > So maybe it needs more time. > > That time will help only if someone will work on developing that > mode. I won't any time soon; volunteers are welcome. I agree. Bidi support - being able to turn it on, is welcome. Being able to turn it OFF is also welcome. > > > Bugs reported for Emacs 24 when this variable is nil > > > will go to the bottom of my todo list. > > > > Clear enough, I guess. You closed this bug with lightning speed. > > Please get your facts right. The bug is not closed. I never closed > it. Sorry; I'm not very clear on the status codes/terminology. This is the fact I was referring to: tags 9571 + wontfix So I guess you're saying that it is not closed but it won't be fixed. Nuance. Limbo is apparently no more (and perhaps never was), but Wontfix is alive and well. > > > So by pressing for this user option you actually do > > > them a disservice. > > > > No, I think I do "them" a service. By refusing to make it > > a user option and refusing to debug and support the nil case, > > I think you do "them" a disservice. > > Anything can be turned on its head by clever word juggling. What word juggling? Are you now saying that you do _not_ refuse to debug the nil case and you _will_ support it? I was trying to state your position accurately, but I'll be happy to hear if I misrepresented it. > But the truth is still there: given the current design and > implementation of the bidi display, I never said you could not modify the implementation. On the contrary. Based on your statement that the implementation does not support the nil case yet, I encourage work on fixing that. > you are encouraging them to use unsupported mode, Not at all. Emacs 24 has not yet been released. We still have a chance to get it right. Until Emacs 24 has been released, talking about supported/unsupported mode simply expresses your desire that you not support the nil case. > whereas I encourage them to use a mode that is fully supported and > whose bugs are being fixed in a matter of days if not hours. I too am happy to see them use the bidi-ON mode. And I am happy to see your level of support for it. > > You've essentially said that there can be no other > > design/implementation that lets users turn this off cleanly. > > There _could_ be a different design, but it's too late to talk about > that now, that the existing design and implementation are what they > are and my free time, age, and amount of energy are what they are. The release is not out yet. If the cake is not fully baked, maybe it shouldn't be served quite yet. > > You are taking an implementor point of view, and you are > > the expert there. I have nothing to say about that. I am taking > > a user point of view (and speaking for only one user), ignorant > > of the design. > > Ignorance is not always a bliss. I took time to explain the > implementation because (I hope) those explanations can help you and > others understand why pressing for making this a user variable is not > TRT, in practical terms. Armed with this new knowledge, I trust > interested users, including you, to draw their conclusions. So far, it seems (but I can't speak for him, obviously) that Richard is not convinced either. He has repeated the same thing as I: why shouldn't this be a user option? And he adds, "Why should [unidirectional display] ever be deleted? What is gained by deleting it?" I have no opinion about that. My only concern is that users be able to, and know how to, turn bidirectional display off. I mention Richard here because he is more likely than I to listen to and understand correctly the explanations about the design. > > If design/implementation concerns mean that users can have > > no option about bidi, then so be it. I can't speak to that. > > That's your call. So far, however, I see `bidi-display-reordering', > > and my understanding is that it gives users some control. > > It's only a partial control, and the result is a weird creature that > is neither pre-Emacs 24 display nor full bidi-aware display. Emacs has been about partial control, better-than-nothing, and do-the-best-we-can, since its inception. Above all, it has been about giving users as much control as possible. And about making things transparent (clear) to users, including about how partial the control might be. That, in particular, is not something we have hidden from users - unlike the case for some non-free software. > IOW, the result is incoherent. It will probably work most of > the time, And that's about as good as one can say for most of Emacs. > but I cannot bet on that. No one is asking you to bet. This bug report only asks that you make the variable, which already exists, which already gives users "partial control", and which already "probably work[s] most of the time", into a _user option_. And that you clearly document how to turn things off (so far as that can be done). No one is asking more than that. If you do not want to, or we do not have the resources to, make the nil case work perfectly, then we will anyway live with it being imperfect. It's about giving users the knowledge and access, even if the results of using nil are not 100% predictable or 100% good. > Whether you want to use such a creature is your > call now, that I explained the meaning as clear as I could. It's not about me. It has never been about me. I might turn it on or I might turn it off. If I get the impression that it slows things down I might try turning it off. If I get the impression that it has no negative effect I might turn it on. I now know how to turn it off (as much as is possible), thanks to the knowledge you communicated - here and in the manual. But other users might not know that. I would prefer that we offer a user option. Not for me, but for others, who might not be so clear about Lisp, buffer-local variables, and `setq-default'. > > OK, so a user cannot turn it off completely. It would be > > good to document that, e.g., in the doc for > > `bidi-display-reordering': just what it does and does not > > affect. > > So now we are requested to document deeply internal details of the > current implementation, and in the user manual at that? That's you saying that, not I. Here is your text I was responding to, in fact: >>> 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. Unthinkable that the settings behave like that - maybe. But what's quite thinkable is that users of the variable that you documented might want to know that it does not turn off reordering of the mode line etc. Telling them that - just what you told us here, is not "document[ing] deeply internal details of the current implementation" - please don't exaggerate. That is simply presenting a caveat, documenting a few special cases so users don't expect something different in those cases. > Do you understand what kind and amount of highly technical stuff > will have to be in the manual in order to explain this in enough > detail for users to understand it? What kind and amount of "highly technical stuff" did you have to go into, to communicate to us those few corner cases? I didn't see _anything_ highly technical in what you said, but what you said helped me know what to expect for the mode line etc. Other users deserve the same info. > How far can you go ad absurdum, Drew? You are the one stretching things, Eli. You give us a sentence that makes clear not to expect turn-off of reorder in cases a, b, and c. When I say, great, thank you, please tell that to the users also, you freak out and start screaming too "highly technical" and "deeply internal" for users. Ad absurdum, indeed. No one is asking that you document the implementation. Think in terms of what might help a user who does happen to set the variable to nil. That's the kind of info that it could be helpful to add to the manual. Nothing more. > > But to the extent that they _can_ turn it off, there is > > apparently a way: `bidi-display-reordering'. > > That way lies madness, if you ask me. At least in the long run, if > not today. You are free to go there, of course: it's a free world > (most of it). So you introduced, and documented in the user manual, something that leads to madness? That's not my doing. > > > But it is _not_ a user setting. > > > > Precisely what this bug thread is about. Please make it a > > _user_ setting, if you can. That's the request. > > It doesn't take a bidi expert to add a defcustom. I will object to > that, for the reasons I explained, and I certainly won't do it > myself. But I cannot force others not to do that. What do you call tagging the request for that as "wontfix"? > > > 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. > > > > So it needs more work, it sounds like. > > If we can find someone to invest that work. We agree that would be a good thing. So at least this bug should be classified "wishlist" instead of "wontfix". > > > IOW, your mental model of this variable and its effects > > > is profoundly wrong. > > > > You've clarified things for my mental model. Now can we > > please fix the design so it DTRT? Let users turn it off > > properly, if you can. > > I have more important things on my table wrt bidi support, and not > enough time. So I won't be working on this in the near future, sorry. Yes, you made that clear with your first reply. In fact, you quickly made it clear that no one else would work on fixing this either: "tags 9571 + wontfix" > > In sum, your message to users seems to be, "If you don't need or > > want bidi then use Emacs 23." > > Please don't put your words in my mouth. Emacs 24 is quite usable as > it is, and there's no need for users to stay with Emacs 23. At least > not users who approach this issue rationally. Then just what words would you like to use to end the sentence "If you don't need or want bidi then use..."? Don't let me put words in your mouth - you tell us how the sentence ends, please.