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

[Lars Magne Ingebrigtsen]

Chong Yidong <address@hidden> writes:

> Still, it seems better not to change Gnus to proactively insert LRM
> characters, but leave it to those users who care to customize it as
> necessary.  In the default value of gnus-summary-line-format,
>
>   "%U%R%z%I%(%[%4L: %-23,23f%]%) %s\n"
>
> the subject (%s) is followed by a newline.  If a user wants to change
> this to include, say, the article number, that could be done via
>
>   "%U%R%z%I%(%[%4L: %-23,23f%]%) %s\u200E%N\n"

After reading through (ok, skimming :-) this thread, I'm also leaning
towards this as the solution (or "solution") for Emacs 24.1 at least.

However, there are complications.  :-)

Basically, people compose their own summary lines.  Even if we do what
Eli suggests, and default to putting in directional characters by
default, this won't really help the people who have customised their
summary buffers.

The additional additional complexity here is that the format specifiers
are complicated in and of themselves.

If we look at the typical elements in a summary line, it's pretty l2r,
except the "from" and "subject" elements, which may be l2r or r2l.  It's
not clear to me how this partitioning would be expressed reliably with
characters.

Take the default "from" spec, which is this: "%-23,23f".  This means
"pad to 23 characters, and chop off bits that are longer than 23
characters".  The "from" is available in a dynamic variable that's
inserted in the buffer by the format-spec machinery.  If I pad the
"from" with segmentation charaters at the start and end, so that
`gnus-tmp-from' becomes "\200Lars Lalala Ingebrigtsen\200", the last
directional character will be chopped off, and the bidi machinery will
wreak havoc with the characters that come afterwards.

In other words, the segmentation characters probably has to be inserted
in the format spec explicitly by users that customise this thing.  Which
just seems like a bad interface.

(And I haven't even mentioned the extra problems that comes with the
code that generates the summary lines is actually stored in each user's
.newsrc.eld file, so even if we somehow find a way to change the
format-spec machinery to be able to "mark" special specifiers to (sort
of) add segmentation characters "around" them, we're not totally out of
the woods.  But that could be solved somehow, I guess.)

So, how would I solve this conundrum?  I'd use text properties.  :-)

That is, Gnus would propertise `gnus-tmp-from' with `line-segment'
`from'.  The rendering engine could then look at line segments
(i.e. consecutive ranges of characters with identical `line-segment'
text props) and do the bidi thing on each segment separately. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/