IT testing for multiple characters (ִרֹ) that occupy 1 display string.

IT testing for multiple characters (ִרֹ) that occupy 1 display string.

[Keith David Bershatsky]

I am working on feature requests #17684 (crosshairs) and #22873 (multiple fake cursors).

When using move_it_in_display_line_to, ִרֹ is treated as one display string; however, it is 3 different characters occupying 3 HPOS.  it->c only reports 1460.

I initially guessed that this was a composition situation, however, it.what returns a 0, which is the same as any other regular character.

Q:  How do we test for this situation, so that we know all of the different characters and each of their individual pixel widths?

Thanks,

Keith

Re: IT testing for multiple characters (ִרֹ) that occupy 1 display string.

[Eli Zaretskii]

> Date: Sun, 30 Sep 2018 17:14:04 -0700
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> When using move_it_in_display_line_to, ִרֹ is treated as one display string; however, it is 3 different characters occupying 3 HPOS.  it->c only reports 1460.
> 
> I initially guessed that this was a composition situation, however, it.what returns a 0, which is the same as any other regular character.

It is definitely a composition, but you've put the individual
codepoints in the wrong order, at least in your email.  The correct
order should be: first u+05e8, the base character, and after that
u+5b4 (1460 decimal) and u+5b9, in any order.

Here's what Emacs reports about this composition on my system:

	       position: 1 of 3 (0%), column: 0
	      character: ר‎ (displayed as ר‎) (codepoint 1512, #o2750, #x5e8)
      preferred charset: unicode (Unicode (ISO10646))
  code point in charset: 0x05E8
		 script: hebrew
		 syntax: w 	which means: word
	       category: .:Base, R:Right-to-left (strong)
	       to input: type "C-x 8 RET 5e8" or "C-x 8 RET HEBREW LETTER RESH"
	    buffer code: #xD7 #xA8
	      file code: not encodable by coding system iso-latin-1-dos
		display: composed to form "רִֹ" (see below)

  Composed with the following character(s) "ִֹ" using this font:
    uniscribe:-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso10646-1
  by these glyphs:
    [0 2 1512 696 8 1 6 6 0 nil]
    [0 2 1465 662 8 4 5 8 -7 [-9 0 0]]
    [0 2 1460 657 8 4 5 -1 2 [-9 0 0]]

> Q:  How do we test for this situation, so that we know all of the different characters and each of their individual pixel widths?

If I put a breakpoint in move_it_in_display_line_to, at or after the
call to PRODUCE_GLYPHS, I see a composition:

  (gdb) p it->what
  $2 = IT_COMPOSITION
  (gdb) p it->c
  $3 = 1512
  (gdb) p it->cmp_it
  $4 = {
    stop_pos = 1,
    id = 0,
    ch = 1465,
    rule_idx = 2,
    lookback = 1,
    nglyphs = 3,
    reversed_p = false,
    charpos = 1,
    nchars = 3,
    nbytes = 6,
    from = 0,
    to = 3,
    width = 1
  }

The nchars and nbytes members of the cmp_it structure clearly show
that Emacs composes 3 characters whose combined length in the internal
buffer representation is 6 bytes.

You didn't tell how and where you took the iterator information, so I
don't know why this didn't look like a composition to you.  Maybe you
had the codepoints in the wrong order, like in your mail, in which
case the u+5b4 character will indeed not compose with the other 2.

As for knowing how many pixels this composed character takes -- the
answer as the same as with any other display element: you subtract the
X coordinate (it->current_x) before the glyph from the X coordinate
after it.

Re: IT testing for multiple characters (ִרֹ) that occupy 1 display string.

[Keith David Bershatsky]

Thank you, Eli, for helping me to understand how to analyze composition characters. 

I had disabled auto-composition-mode several years ago in my init.el, which affected the ability to compose the characters.

When creating the email seeking assistance, I probably copied what should have been just one composition character, along with one-half of another composition character.

I am now able to properly test the existence of a composition character when moving IT.

As always, your help is greatly appreciated!

Keith