GNU bug report logs - #9571
24.0.50; user option to turn off bidi, please

Previous Next

Full log

View this message in rfc822 format

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 9571 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stepnem <at> gmail.com
Subject: bug#9571: 24.0.50; user option to turn off bidi, please
Date: Sat, 24 Sep 2011 03:13:45 +0200

On Sat, Sep 24, 2011 at 02:32, Drew Adams <drew.adams <at> oracle.com> wrote:

> As Eli has said, we don't need his valuable time and
> expertise for that.

He's already been useful in this message thread by explaining that
setting the variable to nil does not do what people thinks it does.

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

OK.

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

Eli has said that he won't oppose someone adding the defcustom, so you
can do both (sending a patch to add the defcustom, and remove the
wishlist tag from the bug).

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

Of course. I just added today a wishlist item for datagram sockets on
Windows, knowing full well that there aren't many people with the
knowledge and the inclination to spend time implementing them. But
experience of years shows that redisplay engine experts are few and
far between. We can leave this as a wishlist, it's just that it won't
likely serve any useful purpose.

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

I meant, your preference of the display enginge being able to be
turned off, even if you personally wouldn't want to do it.

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

Why, pray tell, thinking of me? Because I'm nitpicky enough to answer
to that, or because being a Spaniard I'm more likely to be Catholic
(which I theoretically am, but not in fact)?

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

It's not that I chose to cut these words, is that I was only replying
to the first words. So:

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

Yes. But the fact is, the position of the Catholic Church has not
changed, recently or otherwise. Belief in the limbo has traditionally
been, and still is, something that is not doctrine, but does not
contradict doctrine. That's why I commented your "Limbo is apparently
no more" and let the rest aside. I wasn't interested in discussing
limbo's theology with you, but inform you that the news reports were
far off the mark.

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

Sums up the situation quite accurately. Which is unrelated to any
recent change of status.

> Then so is the same variable as a NON-option bogus.

No, if its intended use is helping in debugging.

> You cannot have it both ways.  Either this is something useful for users to know
> about or it is not.

And i don't want it both ways. I think is not useful for users to
know. Note "useful". I'm not saying that they shouldn't be able to
know it. Also note "I think". That's an opinion, I'm not claiming to
know for a fact that it is not useful for them. No one really knows.

> Who knows?  Do you?

I don't know, and neither do you. You ask for I change, I don't. So
when the masses come here to bring down the walls, we can relent and
give them the defcustom (I'm feeling generous today). Until then, it's
customizability for customizability's sake.

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

Yes. It doesn't seem appropriate for the manual. But we have lot of
docstrings that say: "internal use only" or somesuch.

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

Because it will create the false belief that it does something useful,
so some users will mistakenly shot themselves in the foot.

If you mean: why am I opposed to making the display engine have two
code paths, one with bidi support and one without it, switchable with
a flag... I'm neither for nor against, except that it will be a lot of
work that nobody wants to do, it will make the display engine still
harder to study (I'm just repeating what Eli said a few messages ago),
and it's not clear that it will serve any useful purpose.

> 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'?

I know lots of things, for lots of reasons, that are just garbage
and/or non-useful. I don't see why should I try to help everyone know
these things. I won't try to preclude anyone to learn them, of course,
but I won't help anyone by getting them to learn to say "please" in
irish, memorize an obsolete definition of the meter, or be able to
recite the full name of the female protagonist of "The Fifth Element".
More power to Jane Doe if she wants to read the Emacs Lisp Reference
and know how to setq-default bidi-display-reordering. No one is really
going to try to stop her.

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

Is that what I'm proposing? "Keeping it to myself"? I wasn't born
knowing elisp, you know; and neither had I to submit to some hermetic
mysteries' initiation to be allowed to read the manual. Quaerendo
invenietis.

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

A very small mountain, perhaps. A couple cubic meters of dirt, tops.

> You forgot a paren.)

Let down by cut&paste :-(

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

Glad to hear it.

    Juanma

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.