GNU bug report logs - #73752
29.4; Ligatures are randomly rendered with extra spaces

Previous Next

Package: emacs;

Reported by: xuan <at> xlk.me

Date: Fri, 11 Oct 2024 21:40:02 UTC

Severity: normal

Merged with 54646

Found in versions 29.0.50, 29.4

Fixed in version 30.1

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tim Ruffing <dev <at> real-or-random.org>
Cc: dev <at> real-or-random.org, Visuwesh <visuweshm <at> gmail.com>, xuan <at> xlk.me, 73752 <at> debbugs.gnu.org
Subject: bug#73752: 29.4; Ligatures are randomly rendered with extra spaces
Date: Wed, 30 Oct 2024 19:46:05 +0200
> From: Tim Ruffing <dev <at> real-or-random.org>
> Cc: dev <at> real-or-random.org, eggert <at> cs.ucla.edu, 73752 <at> debbugs.gnu.org
> Date: Wed, 30 Oct 2024 18:34:14 +0100
> 
> 
> > > pp is calling Emacs to print to its stderr.  If that is redirected
> > > somewhere else you won't see the output.
> > 
> 
> Ah, this was the right hint. I'm using emacs in daemon mode, started
> from systemd, so I can inspect stderr via journalctl.
> 
> ------
> 
> Broken rendering for ligature "===" starting at pos 1290 (emacs happens
> to be in daemon mode)
> 
> [...]
>  39  480: COMP[19 (0..0)] pos=1290 w=20 a+d=20+6 face=39 MB
>  40  500: COMP[19 (1..1)] pos=1291 w=20 a+d=20+6 face=39 MB
>  41  520: COMP[19 (2..2)] pos=1292 w=20 a+d=20+6 face=39 MB
> [...]
> 
> $ 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]]]
> 
> -------
> 
> Proper rendering (emacs happens to be not in daemon mode):
> 
>  39  390: COMP[13 (0..0)] pos=1290 w=10 a+d=20+6 face=39 MB
>  40  400: COMP[13 (1..1)] pos=1291 w=10 a+d=20+6 face=39 MB
>  41  410: COMP[13 (2..2)] pos=1292 w=10 a+d=20+6 face=39 MB
> 
> $ pp composition_gstring_from_id(13) 
> 
>  [[#<font-object "-UKWN-Iosevka Term SS04-regular-normal-normal-*-20-*-*-*-d-0-iso10646-1"> 61 61 61] 13 [0 0 61 5852 10 1 11 11 -4 nil] [1 1 61 5896 10 -1 11 11 -4 nil] [2 2 61 5891 10 -1 9 11 -4 nil]] 
> 
> 
> Both sessions are still running. I Hope this helps. Let me know if need
> more remote hands.

Did the "bad" display start from "good" at the beginning of a session?
Or did it start from "bad" to begin with?  If the former, the next
idea is to put a watchpoint on the cached composition in a session
with "good" display, and then do whatever it takes to make it "bad",
hoping that the watchpoint will break at some point and show us the
code which replaces nil with these [X-OFF Y-OFF WADJUST] vectors.




This bug report was last modified 252 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.