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

[Drew Adams]

> > > 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.