emacs-devel
[Top][All Lists]
Advanced

[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: Fri, 09 Mar 2012 12:02:16 +0200

> Date: Fri, 09 Mar 2012 11:45:46 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> 
> Btw, at least on the screenshot you sent, the display of #x64C is
> incorrect.  Compare with what you see when you type "C-u C-x =" for
> that character.

The display in "C-u C-x =" is generated by this snippet (from
descr-text.el):

  (insert (char-code-property-description 'decomposition '(#x64C)))

Somehow, using this produces a correct display of the character
(albeit enclosed in quotes) without any problems.  Perhaps Handa-san
could explain what kind of magic the above does, as compared to simply
inserting the same character into the buffer.  The only sign of magic
I see is this:

  (char-code-property-description 'decomposition '(#x64C))

   => #("'ٌ'" 1 2 (composition ((1 . "  ٌ       "))))

So the string produced by char-code-property-description has the
`composition' text property on the character we want to display.
The value of the text property, in case you wonder, is this:

   ((1 . "\t\x64C\t"))

But how does this countermand the problems is a mystery to me; the
ELisp manual says about the value of this property:

  `composition'
       This text property is used to display a sequence of characters as a
       single glyph composed from components.  But the value of the
       property itself is completely internal to Emacs and should not be
       manipulated directly by, for instance, `put-text-property'.

(A.k.a.: "this is need-to-know only, and you don't need to know".)

Anyway, maybe we could use something like this in generating the
keyboard layouts by quail.el.




reply via email to

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