[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: Re: bidi-display-reordering is now non-nil by default
Date: Sat, 06 Aug 2011 19:17:44 +0300

> From: Lars Magne Ingebrigtsen <address@hidden>
> Cc: Eli Zaretskii <address@hidden>,  address@hidden,  address@hidden
> Date: Sat, 06 Aug 2011 17:51:51 +0200
> 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.

Sorry, I don't understand.  Please tell the details.  You are talking
to a man who doesn't use Gnus.  What kinds of customizations are you
talking about?

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

We need to add the directional characters after formatting.  Or modify
the ``format-spec machinery'', whatever that is, to remove characters
in-between, but not the directional marks themselves, or to insert the
marks as part of the formatting in the first place.  If none of that
can fix the problem, please tell the details of why not.

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

This is a non-starter: as I explained elsewhere in this thread, the
reordering code completely ignores text properties.  It just finds the
next character to display; the properties are thereafter considered by
the code that calls the reordering engine.

reply via email to

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