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 22:46:23 +0300 Message-ID: <83fwjnqbxs.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1316807147 17870 80.91.229.12 (23 Sep 2011 19:45:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 23 Sep 2011 19:45:47 +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 21:45:42 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 1R7Bgr-0001Fq-U4 for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 21:45:42 +0200 Original-Received: from localhost ([::1]:52275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7Bgq-0001yx-S5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 15:45:40 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7Bgn-0001qm-C0 for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 15:45:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R7Bgl-0002Co-AE for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 15:45:37 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7Bgk-0002Cd-Ry for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 15:45:35 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R7BhC-00066T-HV for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 15:46: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 19:46: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.131680713823421 (code B ref 9571); Fri, 23 Sep 2011 19:46:02 +0000 Original-Received: (at 9571) by debbugs.gnu.org; 23 Sep 2011 19:45:38 +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 1R7Bgn-00065i-Gh for submit@debbugs.gnu.org; Fri, 23 Sep 2011 15:45:38 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R7Bgk-00065Y-HS for 9571@debbugs.gnu.org; Fri, 23 Sep 2011 15:45:35 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LRZ00A00QLM0800@a-mtaout21.012.net.il> for 9571@debbugs.gnu.org; Fri, 23 Sep 2011 22:45:04 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.8.215]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LRZ009EPQV3ZOG0@a-mtaout21.012.net.il>; Fri, 23 Sep 2011 22:45:04 +0300 (IDT) In-reply-to: <42AFDF737DB84A93858CA84ABA91A84D@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 15:46: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:51739 Archived-At: > From: "Drew Adams" > Cc: , <9571@debbugs.gnu.org>, > Date: Fri, 23 Sep 2011 12:03:57 -0700 > > > 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. > > 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. > > 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. > > 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. But the truth is still there: given the current design and implementation of the bidi display, you are encouraging them to use unsupported mode, 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. > 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. > 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. > 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. IOW, the result is incoherent. It will probably work most of the time, but I cannot bet on that. Whether you want to use such a creature is your call now, that I explained the meaning as clear as I could. > 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? 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? How far can you go ad absurdum, Drew? > 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). > > 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. > > 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. > > 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. > 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.