bug#73752: 29.4; Ligatures are randomly rendered with extra spaces

[Eli Zaretskii <eliz@gnu.org>]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: luangruo@yahoo.com,  73752@debbugs.gnu.org,  xuan@xlk.me
> Date: Mon, 28 Oct 2024 21:48:26 +0530
> 
> > You need to catch this situation in some reproducible recipe.  Because
> > up front I don't understand how is this possible: we cache each
> > composition with its font object, which includes the font size (and
> > also slant, weight, etc.), so a different variant of the same font
> > ought to match only cache entries that use the exact same font.  Or
> > maybe I don't understand well enough what
> > composition_gstring_put_cache does to compute the hash of a
> > glyph-string header (which is the hash key for a composition)?
> 
> Is this hash dependent on the font driver?

No.  Only the font used for the composed characters is recorded, not
the font backend which opened it.  But fonts are managed by the font
backend, so maybe there's some leakage by that way.

> Also, do we clear the composition cache when all the GUI frames of an
> Emacs daemon are deleted?

No, we don't, not directly.  But we clear the face cache, and that
removes the data of the fonts referred by the face cache from the
composition cache.  So it's quite possible the composition cache is
left empty when all the frames are deleted.

> The misalignment goes away when I close all
> the GUI frames of the daemon, and open a fresh new GUI frame.

Next time this happens, try one of these two:

  M-: (clear-face-cache t) RET
  M-: (clear-composition-cache) RET

and see if any of them corrects the problematic display.

Btw, how frequently do you use different frames, and how likely are
you to have different definitions for the same faces on different
frames in the same Emacs session at the same time?

> > But how can this happen?  Without a reproducible recipe, which can be
> > reproduced without waiting for too long, it is very hard to
> > investigate this.
> 
> I have no idea.  This is not easy to reproduce and seems to be heavily
> dependent on the configuration.  Although I use a Cairo build (with
> Lucid toolkit), the misalignment is not as severe as OP says and it
> takes a lot more time to reproduce as well.  I could never come up with
> a reproducer that takes less time.

The only way I see to investigate this is to wait for this to happen,
then attach GDB to Emacs and look at the problematic compositions in
the cache, comparing them to the corresponding compositions in a fresh
Emacs session.  I can tell what to look for with GDB, if that helps.
If we see that two compositions that should be identical differ by
their font objects, say, we'd at least have a lead and a starting
point for further debugging.