Re: bidi-display-reordering is now non-nil by default

[Mohsen BANAN <list-general@mohsen.1.banan.byname.net>]

>>>>> On Fri, 05 Aug 2011 17:54:54 -0400, Chong Yidong <cyd@stupidchicken.com> said:

  Chong> Still, it seems better not to change Gnus to proactively insert LRM
  Chong> characters, but leave it to those users who care to customize it as
  Chong> necessary.  In the default value of gnus-summary-line-format,

  Chong>   "%U%R%z%I%(%[%4L: %-23,23f%]%) %s\n"

  Chong> the subject (%s) is followed by a newline.  If a user wants to change
  Chong> this to include, say, the article number, that could be done via

  Chong>   "%U%R%z%I%(%[%4L: %-23,23f%]%) %s\u200E%N\n"

  Chong> This has the advantage of avoiding inserting the insertion of excess LRM
  Chong> characters by default.  The disadvantage, of course, is that it requires
  Chong> some extra knowledge from users, but we can handle this by adding a note
  Chong> to the docstring.

I am opposed to the direction that you are
advocating.

Instead of discussing merits of tactics, I want us
to first step back and look at where we are and
what we are trying to do.

The topic at hand is:

    Making emacs24 packages bidi-aware

In a previous message a while back, I attempted to
move things towards formulation/articulation of
goals, policies and strategies. My hope was that
those playing a leadership role would build on
that.

Permit me to attempt in formulating some policies
for making emacs24 packages bidi-aware.

 A- We make a distinction between
   receiving/displaying bidi-awareness and 
   sending/originating bidi-awareness.

 B- We consider displaying bidi-awareness of
   emacs24 packages more urgent and more important.

 C- Anytime that an emacs24 package receives
   bidi-input that results in display problems, 
   we consider that a bug and file a bug report.

 D- With respect to displaying, at package level we
   attempt to eliminate bidi specific options.
   Displaying bidi is viewed as omni-present
   through emacs. It is not a feature to be
   opted-in or opted-out -- or require special
   configuration.
 
 E- With respect to originating bidi-awareness,
   bidi specific options are perfectly reasonable.

Now, assuming that the above policies are
reasonable, here are the problems that I see with
the direction that you advocated:

  Chong> Still, it seems better not to change Gnus to proactively insert LRM
  Chong> characters, but leave it to those users who care to customize it as
  Chong> necessary.  In the default value of gnus-summary-line-format,

So, 

  1) You are saying users "who care" must do
     bidi-specific customization to get
     bidi-display to work in Gnus. Which conflicts
     with my (D).

  2) You are saying that it is acceptable to not
     have the LRM for the subject line. In which
     case when a bidi message arrives display may
     be messed up (C).

     Jason pointed to this previously:

  Jason> Users who get a lot of RTL email may be motivated enough to do that, but
  Jason> users who seldom get such mail (and what they do get is probably mostly
  Jason> spam) will still see the muddled up
  Jason> summary line as a bug.

     It is not reasonable for us to accept emacs24
     to only be working right some of the time.

What you suggested, is a neat temporary hack. I
already changed mine to:

(setq gnus-summary-line-format ":%U%R %B %s %-60=\u200E|%4L |%-20,20f\u200E|%&user-date; \n")

And things are lining up better. Thanks.

But let's not just aim for temporary hacks.  Let's
try to eliminate all necessary complexities --
particularly when they require user exposure.

Permit me to also suggest some strategies for
making emacs24 packages bidi-aware.

  - We first put on the table several package use
    cases to bring out problem patterns.

    Thus far, as usage cases we have:
    
      - Gnus Summary mode

      - mail citations

      - XML mode --  Michael Duggan'si nfo was great

    I'd like to suggest a couple more. Bidi
    ramifications to auctex mode. And perhaps
    org's todo. I hope to be following up with
    these soon.

  - These usage patterns will likely demonstrate a
    need for something like a bidi-kit.el Where
    say insertion of LRM/... at string or point or
    ... gets common code. And also become a
    facility for bidi-menu.el features that were
    previously discussed.

  - Based on something like bidi-kit.el provide
    some examples so that in situations where the
    package maintainer is not motivated someone
    else can take care of moving the package
    forward towards more bidi-awareness.

    In other words we need to spread the knowledge
    for making emacs24 packages bidi-aware.

Emacs24 is now in feature freeze stage.  What we
have is what we have. And with what we have, many
bidi-display problems can be properly fixed. It is
a matter of doing it.

In summary, I am opposed to considering proper
display of bidi by packages as an option requiring
special configuration.

...Mohsen