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

[Eli Zaretskii <eliz@gnu.org>]

> From: Tim Ruffing <dev@real-or-random.org>
> Cc: 73752@debbugs.gnu.org, visuweshm@gmail.com, xuan@xlk.me
> Date: Thu, 31 Oct 2024 02:39:09 +0100
> 
> > Then what exactly is the difference between the session with "good"
> > display and the one with the "bad" display?  How come they show the
> > same ligature differently?  What did you do to make them have
> > different looks?
> 
> Nothing (that I'm aware of.) This appears to be non-deterministic.
> Sometimes it works, sometimes it doesn't. And Yixuan seems to say the
> same when he says that this looks like race condition.

If that's the case, we need to understand what causes such a "race
condition".  Emacs is single-threaded, so it's hard to imagine
something like that.

> It will still be useful to figure out what sets the [X-OFF Y-OFF
> WADJUST] vectors instead of nil. After digging into the code a bit, I
> strongly suspect it's composition_gstring_adjust_zero_width.
> 
> I'm not sure if I have the time to verify this in the coming days, I'd
> appreciate if some of the other affected users could give it a try. 
> 
> I'm not claiming that composition_gstring_adjust_zero_width is wrong,
> but if my theory is right that it sets the vector if and only if the
> rendering is bad, then we'll be a step further.
> 
> This function was introduced in
> cd88f6de4be1f8eba1db038b371d769f584be53b because of bug#50951. AFAIU it
> is supposed to correct a grapheme width of 0 pixels to 1 pixel, so that
> won't explain why large spaces are added. But I skimmed bug#50951 and
> there are some mentions that composition_gstring_adjust_zero_width is
> supposed to suppress adding the "space width of the font", which is
> what some people see here, so all of this sounds a bit related. Next
> question would be why emacs thinks that the grapheme width was zero in
> the first place.

The way forward would be to set a breakpoint inside the width == 0
condition in that function:

      if (NILP (glyph) || from != LGLYPH_FROM (glyph))
	{
	  eassert (i > 0);
	  Lisp_Object last = LGSTRING_GLYPH (gstring, i - 1);

	  if (width == 0)
	    {
	      if (NILP (LGLYPH_ADJUSTMENT (last)))  <<<<<<<<<<<<<<<<<<<<<<<<<
		LGLYPH_SET_ADJUSTMENT (last,
				       CALLN (Fvector,
					      make_fixnum (0), make_fixnum (0),
					      make_fixnum (LGLYPH_WIDTH (last)
							   + 1)));
	      else
		ASET (LGLYPH_ADJUSTMENT (last), 2,
		      make_fixnum (LGLYPH_WADJUST (last) + 1));
	    }

and see if it ever breaks in the scenario(s) where you see the
corrupted display.

In my testing, that breakpoint never breaks, which is consistent with
the fact that none of the glyphs we compose have zero width.  They
don't have zero width in your "broken rendering" case, either:

> $ pp composition_gstring_from_id(19)
>  
>  [[#<font-object "-UKWN-Iosevka Term SS04-regular-normal-normal-*-20-*-*-*-d-0-iso10646-1"> 61 61 61] 19 [0 0 61 5852 10 1 11 11 -4 [0 0 20]] [1 1 61 5896 10 -1 11 11 -4 [0 0 20]] [2 2 61 5891 10 -1 9 11 -4 [0 0 20]]]

(The width is the 5th component of the glyph vector, and they are all
positive there.)  Same in the example shown by Visuwesh:

> Misaligned:
> 
>     [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-15-*-*-*-m-0-iso10646-1"> 45 45 62] 2231 [0 0 45 1970 9 0 9 7 -4 [0 0 10]] [1 1 45 1969 9 -1 10 7 -4 [0 0 10]] [2 2 62 2728 9 -1 9 11 0 [0 0 10]]]

So there's something we are missing here.

Also note that in Visuwesh's case the WADJUST element corresponds to
the width of the previous glyph (9 + 1 = 10), but in your case it
doesn't (11 + 1 ≠ 20).  So this is another mystery.

There are a few calls to lglyph-set-adjustment in composite.el, which
could be responsible for this.  So if the breakpoint inside
composition_gstring_adjust_zero_width never breaks in your sessions,
either, the next step is to put a watchpoint on the cached composition
created by font-shape-gstring and wait for some code to modify the
adjustment part.