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

[Kenichi Handa]

In article <address@hidden>, Eli Zaretskii <address@hidden> writes:

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

The function body I wrote is just an idea, not a complete
solution, and of cource checking against L is apparently
a bug.  At least we must check against R (and AL).

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

Why?  Keyboard cells in the keyboard layout has typically
this form: (L is for lower key, U is for upper (shifted) key)

... | LU | LU | ...

What we want is to display the left LU to the left of the
right LU, and display each L (character or string) to the
right of the corresponding U.

Even if the L (of the left LU) is ".A", we don't need LRM
for it.  We have to insert LRM only before a character that
may reorder the previous characters, and after a character that
may reorder the following character.  Isn't it right?

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

As it's possible to assign a string to a key, there will be
the case that the characters in the string must be
reordered.  In the above case, if L is a hebrew "שלום", it
must be reordered.  But, even if we surround that word with
LRE and PDF, the word itself is reordered correctly, right?

---
Kenichi Handa
address@hidden