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

["Štěpán Němec" <stepnem@gmail.com>]

On Fri, 23 Sep 2011 13:45:35 +0200
Juanma Barranquero wrote:

> 2011/9/23 Štěpán Němec <stepnem@gmail.com>:

>> I still think "there is no way back" is all the more reason to be as
>> helpful and open about the changes and possible problems as possible.
>
> Pretest *is* the moment to discover, and hopefully fix, the possible problems...

It's meant to be, yes, but I suspect most users just wait for the
release. And in any case, clear information about an experimental (or
call it "new", if "experimental" is controversial) feature and related
issues is very useful for pretesters, too.

>> In
>> other words, not clearly saying that bidi might bring problems and how
>> to work around them in the user documentation at this point would only
>> be reasonable if Emacs bidi was pretty much a solved problem, but that's
>> really not the impression I got from the related emacs-devel discussions
>> or even from your explanation.
>
> That's a bit absurd, IMO (no offense intended). New features are never
> a "solved problem" until they have been extensively tested, and then
> some. That has to be done at some point in time. And that moment is
> now.

Some features are more experimental than others, some are more annoying
when gone wrong than others, and some cause annoyances harder to
diagnose than others.

On Fri, 23 Sep 2011 13:50:59 +0200
Eli Zaretskii wrote:

>> From: Štěpán Němec <stepnem@gmail.com>
>> Cc: 9571@debbugs.gnu.org
>> Date: Fri, 23 Sep 2011 13:09:49 +0200
>> 
>> By under-documenting the issue you only provide more opportunity to
>> FUD. In other words, not clearly saying that bidi might bring
>> problems and how to work around them in the user documentation at
>> this point would only be reasonable if Emacs bidi was pretty much a
>> solved problem, but that's really not the impression I got from the
>> related emacs-devel discussions or even from your explanation.
>
> I happen to be a documentation freak, and tried to do my best in
> documenting everything related to bidi.  If you can suggest specific
> changes to the user manual or NEWS about this, please do.  Saying in
> the manual that some feature "means trouble" is not something we use
> to do, because users will say "if it's trouble, why don't you fix
> it?".  We need to find a way of saying something useful that will help
> users nonetheless.  Suggestions are welcome.

When you take one example Lars reported recently -- a buffer where the
current bidi code wasn't able to diagnose the paragraph direction
properly (or something) in a relatively untypical buffer (a lot of long
lines without paragraph breaks). It made the buffer unusable. Now, how
would a user diagnose or solve this issue? How would the current
documentation help him in doing so?

The user has to figure out that 1) (a problem with) the bidi reordering
is the cause of the problem 2) they can work around it by setting
bidi-display-reordering to nil. I'm rather sure the current
documentation provides no clue as to point 1) (because it doesn't say
such problems might occur and there is no other way to know), and I'm
not quite sure it provides sufficient clues for point 2) (it says the
variable "controls whether text in the buffer is reordered for display";
is a user with no clue about bidi likely to understand that as "when set
to nil, the text in the buffer should behave just as before the bidi
feature was introduced"? I don't know, but I suspect I might not, if I
hadn't seen previous comments and references to the variable and its
effects on emacs-devel and other places).

I think unless you're pretty sure such problems are not likely to occur
again, you should at least say (in NEWS if not in the manual; I would
probably check the NEWS first in such situation anyway) that such things
can happen and how to work around it (and you should probably also say
that bidi is here to stay anyway so disabling it is only a workaround,
encouraging users to report issues instead of just turning bidi off).

-- 
Štěpán