[Top][All Lists]

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

Re: bidi and shaping problems in describe-input-method

From: Eli Zaretskii
Subject: Re: bidi and shaping problems in describe-input-method
Date: Mon, 12 Mar 2012 19:42:41 +0200

> From: Kenichi Handa <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Mon, 12 Mar 2012 16:47:11 +0900
> In article <address@hidden>, Eli Zaretskii <address@hidden> writes:
> > Yes.  But surrounding each `lower' and `upper' key labels in the
> > layout with LRE..PDF inserts even more bidirectional control
> > characters than just inserting LRM.  By contrast, using LRO..PDF
> > around the whole row of keys inserts just 2 such characters, so if it
> > were not for the need to reorder the individual key labels, LRO..PDF
> > would be a better alternative.  I mentioned it because it does exactly
> > what you originally asked for: it effectively disables
> > bidi-display-reordering inside the embedded text, while still leaving
> > the rest of the buffer reordered as usual.
> I mixed up with LRE and LRO, sorry.  Anyway, if LRO..PDF
> works, it is surely better than many LRMs.  I've just
> installed a proper change including the magic of
> compose-string.  Please try the latest code.

It works fine for me, thanks.

However, using LRO..PDF means that no label on a key can use a string
that needs to be reordered.  That's because the LRO overrides the
bidirectional properties of all the following characters to be strong
L.  If we can live with this limitation, I agree that this is better.
But I think you said earlier that such a restriction is more than we
can bear.

reply via email to

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