From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: 9571@debbugs.gnu.org, lekktu@gmail.com, stepnem@gmail.com
Subject: bug#9571: 24.0.50; user option to turn off bidi, please
Date: Fri, 23 Sep 2011 22:46:23 +0300 [thread overview]
Message-ID: <83fwjnqbxs.fsf@gnu.org> (raw)
In-Reply-To: <42AFDF737DB84A93858CA84ABA91A84D@us.oracle.com>
> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <stepnem@gmail.com>, <9571@debbugs.gnu.org>, <lekktu@gmail.com>
> 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.
next prev parent reply other threads:[~2011-09-23 19:46 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-22 4:18 bug#9571: 24.0.50; user option to turn off bidi, please Drew Adams
2011-09-22 5:49 ` Eli Zaretskii
2011-09-22 12:31 ` Stefan Monnier
2011-09-22 13:13 ` Drew Adams
2011-09-22 21:44 ` Richard Stallman
2011-09-23 4:13 ` Stefan Monnier
2011-09-23 12:31 ` Richard Stallman
2011-09-23 14:46 ` Eli Zaretskii
2011-09-23 14:55 ` Lars Magne Ingebrigtsen
2011-09-23 15:06 ` Eli Zaretskii
2011-09-23 17:36 ` Stefan Monnier
2011-09-23 18:23 ` Lars Magne Ingebrigtsen
2011-09-23 19:44 ` Richard Stallman
2011-09-23 20:09 ` Eli Zaretskii
2011-09-24 3:56 ` Jason Rumney
2011-09-24 12:28 ` Richard Stallman
2011-09-23 9:13 ` Eli Zaretskii
2011-09-23 12:31 ` Richard Stallman
2011-09-23 14:40 ` Eli Zaretskii
2011-09-23 19:44 ` Richard Stallman
2011-09-23 19:48 ` Eli Zaretskii
2011-09-24 12:28 ` Richard Stallman
2011-09-24 14:04 ` Eli Zaretskii
2011-09-24 17:30 ` Richard Stallman
2011-09-24 19:15 ` Eli Zaretskii
2011-09-24 23:52 ` Richard Stallman
2011-09-23 4:11 ` Stefan Monnier
2011-09-23 8:01 ` Štěpán Němec
2011-09-23 9:21 ` Juanma Barranquero
2011-09-23 10:39 ` Štěpán Němec
2011-09-23 11:01 ` Eli Zaretskii
2011-09-23 16:09 ` Drew Adams
2011-09-23 17:48 ` Eli Zaretskii
2011-09-23 19:03 ` Drew Adams
2011-09-23 19:46 ` Eli Zaretskii [this message]
2011-09-23 21:23 ` Drew Adams
2011-09-23 23:21 ` Juanma Barranquero
2011-09-24 0:32 ` Drew Adams
2011-09-24 1:13 ` Juanma Barranquero
2011-09-24 3:46 ` Drew Adams
2011-09-24 8:44 ` Juanma Barranquero
2012-02-22 2:34 ` Glenn Morris
2011-09-24 6:49 ` Eli Zaretskii
2011-09-24 8:46 ` Juanma Barranquero
2011-09-23 20:00 ` Stefan Monnier
2011-09-23 10:18 ` Eli Zaretskii
2011-09-23 11:09 ` Štěpán Němec
2011-09-23 11:45 ` Juanma Barranquero
2011-09-23 13:01 ` Štěpán Němec
2011-09-23 15:03 ` Eli Zaretskii
2011-09-23 17:46 ` Stefan Monnier
2011-09-23 18:24 ` Eli Zaretskii
2011-09-23 19:10 ` Eli Zaretskii
2011-09-23 11:50 ` Eli Zaretskii
2011-09-24 12:28 ` Richard Stallman
2011-09-24 14:13 ` Eli Zaretskii
2011-09-24 3:53 ` Jason Rumney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83fwjnqbxs.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=9571@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
--cc=lekktu@gmail.com \
--cc=stepnem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.