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

[Drew Adams]

> > sn> OOH, there was a time when suggesting that the user adds 
> > sn> something to .emacs, like (setq-default 
> > sn> bidi-display-reordering nil)
> > sn> was not considered obscure. Not everything must go
> > sn> through the customization interface.
> > 
> > First, we have _not_ suggested that to users.
> 
> Because it's _not_ a user variable.

Not yet.  That's precisely the bug that this thread is about.

> > Currently, users need to figure out for themselves that the 
> > variable exists, what it does, and that it is buffer-local.
> > And they need to learn about buffer-local variables and
> > `setq-default'.
> 
> No, they aren't required to.

If they want to turn off bidi support, they are.
That's what this thread is about.

> > But that does not mean that we should not make it very 
> > clear to users how they can easily turn it off.
> 
> 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?

Please keep a user, not just an implementor, point of view here.

> That variable exists for 2 purposes only: (a) let interested
> individuals, such as myself, see if some problem could be due to the
> bidi-aware parts of the display engine, and (b) allow Lisp code to
> turn off bidi reordering where it is needed.  I don't mind you or
> others take advantage of this variable if they so prefer.

Thank you.

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

> IOW, when you set bidi-display-reordering to nil, all bets
> are off regarding the correctness of the display operation,

So maybe it needs more time to become fully baked.

> because I do that only very rarely (lately almost never),
> and only for specific debugging purposes.  I cannot in
> good faith recommend that users use this mode because I
> don't use it enough to vouch for its correctness
> and its being free of bugs.

More time needed to test and make it correct, it sounds like.

> You are on your own when you use this mode.

Which means you are on your own when you use Emacs 24.

Oh, sure, you'll support bidi on, but not bidi off.
And anyone who wants it off can just use Emacs 23...

> 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.  If Richard
hadn't chimed in, I suppose it would have died instantly.

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

Just one opinion.  And yes, a completely _naive_ opinion wrt the
design/implementation.

You've essentially said that there can be no other design/implementation that
lets users turn this off cleanly.  If that's true then OK, there's nothing more
I can say about this.

> I realize that you do that because you are not aware of
> the extent of changes done to the Emacs 23 display code.

The latter is certainly true.  But that is not the reason why I "do that".

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.

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.

> That's why I say this: now you do know.

Yes, it's clear that you will support the new feature, but not turning it off.
To me, that's unfortunate.  But maybe it's the best we can hope for.

> > We already have a way for users to turn bidi off, and that's good.
> 
> No, we don't.  What you call "bidi" cannot be turned off, not
> entirely.  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.

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.

But to the extent that they _can_ turn it off, there is apparently a way:
`bidi-display-reordering'.

> > But the proper test is not whether using `setq-default'
> > for this is good enough for you [SN] or this or that
> > Emacs-Lisp aficionado.  Users should be able to turn
> > bidi off using Customize, IMO. This is a _user_ setting. It 
> > is a _user's_ choice whether to turn bidi support off.
> 
> 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 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.

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

> > ez> ??? The variable and its effect are clearly documented 
> > ez> in both the user manual and the ELisp manual. 
> > 
> > Documented, yes, but not clearly. You do not state
> > clearly that to turn off bidi support in a given buffer
> > you need to set the variable to nil, and to turn it
> > off generally you need to `setq-default' it to nil.
> 
> Because it's not a user option.  Variables that are not user options
> are normally not documented at all in the user manual.  I went out of
> my way in this matter.  More information about this (including the
> effect of setq-default for this variable) can be found in the ELisp
> manual, and I wrote it there because I consider that manual to be
> important for Emacs maintainers, not just for ELisp programmers.

See above.  It _should_ be a user option, if possible.  That's the point of this
thread - see the Subject line.

Even in its current state, the doc is not helpful enough to users.  See above.
Saying that the doc should not help users because this is not a user option is,
well,...

> You are asking for something that is not in the design.

I believe you.

> > rms> It has to be easy to do, so why NOT do it?
> > ez>
> > ez> Because the unidirectional display will one day go 
> > ez> away, and having a user option will be an obstacle
> > ez> to getting rid of it.
> > 
> > When it does go away, so will the option to disable it.
> > The fact that it might one day go away is no reason not
> > to have an option NOW to disable it.
> 
> That is a naive and unrealistic view of software maintenance.

Why would a user option that no longer has any effect not be removed?  We've
done that lots of times.

> Users who will customize this option

Glad to hear you thinking in terms of that possibility.

> on their .emacs file will object to the change, and
> rightfully so.

Maybe, maybe not.  Depends what the non-nil state of things is at that point,
and depends on user needs and expectations at that point.  With your expected
scenario, everyone and her brother will _want_ to use non-nil anyway, so no one
would object.

Anyway, Emacs Dev has lots of times made changes over user objections.
Especially if there are very few objectors (which is what you and I both
expect), that's not a problem.

> The result will be slow and painful process that will
> take years.  We have been there more than once.

Sorry, I don't see it that way.  That sounds a bit like scare tactics, to me.
You might be right, or not.  I don't see the sky falling because Emacs Dev wants
to remove a user option that no longer has any effect.

> For once, I'd like to try doing this The Right Way,

Great.  Then let's please take the time to finish things in such a way that
users can completely and easily turn this on/off.  If you can.

> where things depend on me.  Maybe it's a lost battle,
> but I'd like to try fighting it anyway.

Sounds more like a won battle, to me.  You seem to say that only the current
design is possible; it's impossible to cleanly let users turn it off; if users
do try to turn it off that won't be supported;...  In sum, your message to users
seems to be, "If you don't need or want bidi then use Emacs 23."