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

["Drew Adams" <drew.adams@oracle.com>]

> And that is the case here: the number of people who understands both
> the Emacs display engine and the issues related to bidi can be counted
> with a couple bits, and I'm being generous. So if Eli says that he's
> not going to devote time to some issue related to it, it's not
> unrealistic to expect that it won't happen (soonish).

I think everyone realizes that.  This bug report is about making the variable
into a user option.  As Eli has said, we don't need his valuable time and
expertise for that.

> Your insistence in keeping the issue as a wishlist

I mentioned "wishlist" only after Eli himself indicated that it needs more work
"if we can find someone to invest that work".

I don't think this bug report - which asks for a user option, should be closed,
or classified wontfix (already done), or sent to the wishlist.

I think we should make the var an option now AND (based on what Eli has said)
add an enhancement request to the wishlist for more development to support the
nil value - whether or not Eli is the only one on the planet who could ever hope
to respond to such a wish.

If you exclude things from the wishlist just because there is no one around
today who has the time to work on them, then it is not a wishlist.

> is just the hope that someone will someday want to change
> the display engine to suit your preferences.

No, you haven't been reading what I said.  It's not about my preferences.

I truly have no idea whether I will want this thing on or off, personally, as I
indicated clearly several times.  As I said, if there seems to be no downside, I
will likely just leave it on.

That's even though I do not expect to have any need for bidirectional editing.
Why then?  To closer reflect what others use, including people who might use
some of my code.  As you know, each departure from emacs -Q makes bug reporting
just that much harder.

But again, I have no idea now what I will do, and this bug report has NOTHING to
do with my (nonexistent) preferences wrt the variable value.

> > Limbo is apparently no more
> 
> Not exactly, no. In fact, the official position of the Catholic Church
> has not changed, news reports notwithstanding.
> http://en.wikipedia.org/wiki/Limbo#Modern_era

Thinking, in fact, of you, Juanma, I read precisely that Wikipedia article
BEFORE I wrote that sentence, being personally ignorant and indifferent to
limbosity.

And that is _exactly_ why I added "(and perhaps never was)" immediately
following the words you quoted (but which you chose to cut).

That article makes it clear that the situation wrt the Catholic Church is less
than clear wrt "limbo" - even after P.B. XVI's 2007 publication, and that there
have been multiple notions of "limbo" over the ages, etc.

"And perhaps never was" sums up the situation quite accurately, as I read that
Wikipedia article.  Not that I really care...

> > 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?
> 
> Because the option it would currently offer is bogus.

Then so is the same variable as a NON-option bogus.  And then so is its
treatment in two (count 'em!) Emacs manuals.  I didn't create that variable, nor
did I describe it in the manuals.

You cannot have it both ways.  Either this is something useful for users to know
about or it is not.  If it is, then AFAICT it is just as useful for non-Lispers
as for Lispers, for those who understand `setq-default' and buffer-local vars as
well as for those who do not.

> > 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.
> 
> It has also been about using resources (= developers) in the most
> efficient way possible.

There are two different issues that have been discussed here:

1. Make the variable into an option, and tell users more clearly about what nil
does.

2. Work more on the code to be able to more solidly "support" the nil use case.

This bug report asked only for #1.  As Eli has admitted, it doesn't take much in
the way of resources to do that.  It is Eli, not I, who brought up #2 and
pointed to potential problems if users set the variable to nil.

And let's not be under any illusions about this "support".  Not making it a user
option does not let Emacs "support" off the hook.  The existence of the
variable, and especially its description in both Emacs manuals, means that some
users will likely set it to nil.

> > It's about giving users the knowledge and access, even if 
> > the results of using nil are not 100% predictable or 100% good.
> 
> Are there really that many users that will want to disable
> bidi-display-reordering,

Who knows?  Do you?

> knowing that the result will likely be buggier than the
> default?

But how on Earth will they know that?  Saying anything about that in the doc was
specifically verboten by Eli:

  Saying in the manual that some feature "means trouble" is
  not something we use [sic] to do, because users will say "if
  it's trouble, why don't you fix it?".

> And if they do exist, do they really need a defcustom?

To quote a famous person, why not?  "Why are you opposed to a flag to turn bidi
display off?"

Why should you, Juama, who are familiar enough with buffer-local vars etc. to
understand how to turn this off (if you wanted to), be able to do so; but not
Jane Doe, who understans how to use Customize but knows nothing about
`setq-default'?

Do you "really need" to keep this optional behavior to yourself and others with
Emacs-Lisp knowledge?

> > 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'.
> 
> A defcustom is an statement that something is a switch, and both modes
> are reasonable. That is not the case here.

No more so than for any other variable.  Nothing is guaranteed in Emacs.  User
options no more than other vars.  You are making a mountain out of a mole hill.

> > 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.
> 
> Your defcustom request can be trivially satisfied, and not a word is
> needed in the manual:
> 
> (defcustom bidi-display-reordering t
>   "Not a user option. Do NOT set it to nil.  Horrible things will
> happen.  Thanks." :type 'boolean :version "24.1"

You forgot a paren.)  But I could actually live with that, provided the manual
still describes the variable fairly, as it does now (and hopefully a bit more
clearly wrt what nil does).

I wouldn't choose such a doc string myself, but if that's the price to pay for
giving users an option they can find easily using `apropos-variable' then it
might be worth it. 

But I don't think you'll convince Eli to use such language - see above.