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

From: Eli Zaretskii <[email-masked]>
Date: Tue, 29 Oct 2024 15:04:16 +0200

> From: Visuwesh <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> Date: Tue, 29 Oct 2024 16:29:48 +0530
> 
> >> 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.
> 
> OK, thanks.  I wonder if we could compare the value returned by
> font-info if something has gone wrong with the font object used to
> compute the hash for the glyph?  

That would not be the first thing I'd look at.  According to the
screenshots, it is more likely that a wrong cache entry is used for a
composition, which uses the "wrong" font variant.  IOW, the font used
itself is fine, it just is not the font that's supposed to be used
with the composed characters in that place.

So I would first look at the font object stored in the header of the
cached composition.

> > Btw, how frequently do you use different frames, 
> 
> Quite often, I would say.  I usually have two frames but it can go
> upwards of 5 to 6 if I have a mouse attached to my laptop.
> 
> > 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?
> 
> I don't quite understand this question.  Are you asking if I have any
> "frame-specific" face attributes i.e., non-nil FRAME argument in
> set-face-attribute?

Yes.

> If so, no.

OK, so one more theory eats dust (we don't record the frame in the
composition cache).

> > 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.
> 
> That would help.  But given how hard it is to reproduce this issue on my
> end, I don't know when I can get back...

It would not be useful for me to give instructions before you actually
hit the problem (because the code will change until then), so if you
want to try this, get back to me when you do reproduce the problem
(and then attach GDB and leave the Emacs session under GDB for any
investigations I'd ask you to do).

Thanks.