bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#9571: 24.0.50; user option to turn off bidi, please
Date: Fri, 23 Sep 2011 20:48:25 +0300

> From: "Drew Adams" <address@hidden>
> Cc: <address@hidden>, <address@hidden>
> Date: Fri, 23 Sep 2011 09:09:56 -0700
> 
> 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.

Because it's _not_ a user variable.  The fact that it's documented in
the user manual is already more than we normally would do about such
toggles.

> 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.  They should report any abnormal behavior
as bugs.

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

I cannot be a shrink to myself; maybe it is.  If so, it would only be
human.  I could ask you the same question.  Neither will get us
anywhere nearer to an agreement.  Just drop it.

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

IOW, when you set bidi-display-reordering to nil, all bets are off
regarding the correctness of the display operation, 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.  You are on your own when you use this
mode.  Bugs reported for Emacs 24 when this variable is nil will go to
the bottom of my todo list.

So by pressing for this user option you actually do them a disservice.
I realize that you do that because you are not aware of the extent of
changes done to the Emacs 23 display code.  That's why I say this: now
you do know.

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

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

But it is _not_ a user setting.  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.  IOW, your mental model
of this variable and its effects is profoundly wrong.

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

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.

> If optionhood is good enough for `bidi-paragraph-direction' then it is good
> enough for `bidi-display-reordering' too.

The paragraph direction is (and must be) a user setting.  Only a human
can know better than Emacs what is the correct base direction of the
paragraphs in a document.  Other bidi-aware programs all have
equivalent knobs.  But no other application I know of has an option to
turn off bidi reordering.  They either do it always or not at all.
That's how Emacs's bidi display was designed, too.  You are asking for
something that is not in the design.

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

That is a naive and unrealistic view of software maintenance.  Users
who will customize this option on their .emacs file will object to the
change, and rightfully so.  The result will be slow and painful
process that will take years.  We have been there more than once.  For
once, I'd like to try doing this The Right Way, where things depend on
me.  Maybe it's a lost battle, but I'd like to try fighting it anyway.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]