bug#56237: 29.0.50; delete-forward-char fails to delete character

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: 56237@debbugs.gnu.org
> Date: Mon, 27 Jun 2022 11:17:25 +0530
> 
> >     (let* ((composition (find-composition 0 nil "ப்போ" t))
> >            (gstring (nth 2 composition))
> >            (num-glyphs (lgstring-glyph-len gstring))
> >            (i 1)
> >            (from (lglyph-from (lgstring-glyph gstring 0)))
> >            (to (lglyph-to (lgstring-glyph gstring 0))))
> >       (while (and (< i num-glyphs)
> >                   (= from (lglyph-from (lgstring-glyph gstring i)))
> >                   (= to (lglyph-to (lgstring-glyph gstring i))))
> >         (setq i (1+ i)))
> >       i)
> >
> > here i is the number of characters we need to delete using delete-char.
> >
> > [1] For the gstring format, see composition-get-gstring.
> >
> > But I think we should test this code in cases where a grapheme cluster
> > contains more than two codepoints since all the composed characters in
> > Tamil are made up of two Unicode codepoints.  I can't test it on emojis
> > since I don't know of an Emoji font that won't crash potentially Xft and
> > has enough coverage.
> >
> 
> I got my hopes too high.  :(
> 
> This fails for the simple case of ரு (C-u C-x = also fails!) so I guess
> we are back to square one.  Although ரு is composed from 0BB0 0BC1, the
> gstring only has one glyph.

Yes, composition of N characters can in general produce M glyphs,
where M can be smaller, equal, or greater than N.  It's a many-to-many
operation, and we cannot rely on getting the same number of glyphs as
the number of codepoints we compose.

The idea is nevertheless correct (I had the same one), it just needs
some fine-tuning.  (And "C-x =" tries to solve a different problem:
how to match each glyph with a codepoint, and that problem is in
general insoluble, so it's a small wonder that it fails.)

Please try the latest master, I hope delete-forward-char now behaves
better.