bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9571: 24.0.50; user option to turn off bidi, please


From: Eli Zaretskii
Subject: bug#9571: 24.0.50; user option to turn off bidi, please
Date: Fri, 23 Sep 2011 22:46:23 +0300

> From: "Drew Adams" <address@hidden>
> Cc: <address@hidden>, <address@hidden>, <address@hidden>
> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]