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

[Eli Zaretskii <eliz@gnu.org>]

> From: Kenichi Handa <handa@m17n.org>
> Cc: list-general@mohsen.1.banan.byname.net, emacs-devel@gnu.org
> Date: Mon, 12 Mar 2012 16:47:11 +0900
> 
> In article <8362eczr73.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> 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.