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 bidi-display-reordering nil)
sn> was not considered obscure. Not everything must go through the
sn> customization interface.

First, we have _not_ suggested that to users. To suggest that would be a good
first step.

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, not every user is up on this stuff. It will not be obvious to all users how
they might turn off bidiness. _That is the point of this bug report_: give users
an option and document it clearly as turning off bidi. Make it obvious to users.

It seems clear that you, Eli, are resisting making it obvious how to turn off
this feature you implemented. Is ego mixed in there a bit, perhaps?

Let me be clear (again). Bidi support is a _good_ thing. I was the first to
respond to your announcement of it, saying "Great!". And I admire your work on
it as a real accomplishment.

But that does not mean that we should not make it very clear to users how they
can easily turn it off.

For some reason, this seems to be an emotionally charged issue for some people.
When I first suggested, in emacs-devel, giving users an easy way to turn it off,
I was practically accused (not by you, Eli) of western imperialism, l2r-ism and
nasty asciiness. Nothing could be further from the truth. I'm 100% in favor of
Emacs supporting bidirectional text.

We already have a way for users to turn bidi off, and that's good. I just want
to see it as (a) a user option and (b) clearly advertised (documented).

sn> It's certainly good enough to me, but you won't find that 
sn> advice in the current documentation either, AFAICT.

Correct. Adding it to the doc would be a good first step.

But the proper test is not whether using `setq-default' for this is good enough
for you 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.

ez> ??? The variable and its effect are clearly documented in both the
ez> 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.

As Stepan (sorry about the ASCII/misspelling) replied to you:

sn> (it says the variable "controls whether text in the buffer is reordered for
display";
sn> is a user with no clue about bidi likely to understand that as "when set
sn> to nil, the text in the buffer should behave just as before the bidi
sn> feature was introduced"? I don't know, but I suspect I might not, if I
sn> hadn't seen previous comments and references to the variable and its
sn> effects on emacs-devel and other places).

ez> Which is more than I can say for
ez> the other new features introduced in Emacs 24, because documentation

I agree with Eli about that last sentence, and I applaud his long and continuing
interest in and efforts for the doc - second perhaps only to Richard's.

The bidi stuff is much more, and presumably better, documented than other Emacs
24 changes, so far. A good case in point is the (apparently still volatile)
buffer-display stuff.

ez> What else besides documentation of the variable is needed to make it
ez> clear to users how to turn a feature off?

1. Clearer doc about turning it off, as Stepan pointed out (above).

2. A user option, findable by looking for _options_, e.g. `apropos-variable
bidi' (without C-u).

If optionhood is good enough for `bidi-paragraph-direction' then it is good
enough for `bidi-display-reordering' too. A user trying `apropos-variable bidi',
looking for how to turn bidi off, should find the answer easily.

sn> Also, this is not (only) about making `bidi-display-reordering' a custom
variable.

My bug report _is_ only about providing a user option for this.

rms> It has to be easy to do, so why NOT do it?
ez>
ez> Because the unidirectional display will one day go away, and having a
ez> user option will be an obstacle 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.