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: Fri, 09 Mar 2012 23:03:32 +0900
> 
> In article <83d38m19dk.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > If possible, I'd like to avoid inserting LRM unconditionally.
> 
> > Why?  They are invisible, so they are not displayed at all.
> 
> In general, it's smarter to use LRM only where necessary.

Testing whether they are necessary is a problem in itself.  You can
easily avoid inserting the marks for strong L2R characters, but they
are the minority.  Most of the characters are not in that category.
And of course keyboard layouts include such characters.

> > > (defun quail-help-require-LRM (char)
> > >    (or (eq (get-char-code-property char 'bidi-class) 'L)
> > >        ...))
> 
> > It's possible, but why bother?  And with this function you will insert
> > the LRM for many characters that don't need that, like punctuation,
> > numbers, etc.
> 
> ??? I want a function that returns t only for a character
> that require preceding LRM in the keyboard layout.

Yes, I understand that.  But the test you are suggesting, i.e. avoid
the LRM only for characters whose bidi-class is L, will not catch
numbers, punctuation, and other non-L characters.

> > Also, `lower' and `upper' could be strings, in which case you need a
> > more complex test.
> 
> We can give (if (string lower) (aref lower 0) lower) to that
> function.

But that doesn't DTRT.  Here's an example where it will fail: ".A".

AFAIK, the only reliable way of telling whether a given string will be
reordered is to actually reorder it, and then compare with the
logical-order original.  That's a nuisance, and also the results may
well depend on the characters before and after the string in the
buffer, so you need to know the context in advance, which you normally
don't.

I tried also a different solution: enclose each row of the keyboard
layout in an L2R override embedding, LRO..PDF.  This inserts only 2
control characters per row, and doesn't insert them inside the
keyboard cells, so it is cleaner, I think.  But using this means that
no key description in the layout can be a string that requires
reordering individually.  (By contrast, inserting an LRM between the
lower and the upper key still allows each description to be
reordered.)  Can we live with such a restriction?  I don't know enough
about Quail to tell.