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

[Eli Zaretskii]

> From: Chong Yidong <address@hidden>
> Cc: Werner LEMBERG <address@hidden>, address@hidden
> Date: Mon, 01 Aug 2011 11:45:54 -0400
> 
> I don't know enough to say what the real fix is, though.  You said that
> the slowdown is because "Emacs is searching for the beginning of the
> paragraph, but this whole buffer is one huge paragraph."  Is it enough
> for a mode to set the variable `paragraph-start' for Emacs to DTRT?

No.  The bidi reordering doesn't use the value of `paragraph-start',
because some modes (e.g., Texinfo) set it to something utterly
incompatible with what "paragraph" means in the UAX#9 context.
(Originally, the code did use `paragraph-start', but that caused bad
crashes, so I backed up.)

In general, a "bidi paragraph" must begin after a newline, or else the
Unicode Bidirectional Algorithm, which Emacs implements, would need
serious changes, with the result that compatibility between Emacs and
other bidi-supporting applications would be questionable at best.

We could introduce a separate variable for a "bidi paragraph" start
and separator, but I never tried to see whether the current code will
work well with an arbitrary value of such a variable, not even if its
value is a single newline (i.e. each line is a separate paragraph).
I'd rather not start such an adventure now.

> A quick glance at the Mew source shows that it does set
> `paragraph-start', though I don't know if every line is treated like
> a paragraph.

The issue at hand is with the Mew Summary buffer, not with the buffer
where it displays the mail messages themselves.