GNU bug report logs - #77151
31.0.50; >>= is not rendered

Previous Next

Full log

Message #19 received at 77151 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Roux <mattias <at> kojin.tech>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77151 <at> debbugs.gnu.org
Subject: Re: bug#77151: 31.0.50; >>= is not rendered
Date: Mon, 24 Mar 2025 14:37:14 +0100

[Message part 1 (text/plain, inline)]

Hi Eli,

Thanks for the thorough report :-)

I raised the issue on the FiraCode repository and here's the answer 
<https://github.com/tonsky/FiraCode/issues/1644#issuecomment-2748156170>:

Considering that it works literally everywhere else, it probably has 
something to do with Emacs

https://fonts.google.com/specimen/Fira+Code?preview.text=%3E%3E%3D

Image 
<https://private-user-images.githubusercontent.com/285292/426100705-b69cfdd7-0895-42f1-be0e-f2b0f3a24c90.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDI4MjM2MTEsIm5iZiI6MTc0MjgyMzMxMSwicGF0aCI6Ii8yODUyOTIvNDI2MTAwNzA1LWI2OWNmZGQ3LTA4OTUtNDJmMS1iZTBlLWYyYjBmM2EyNGM5MC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMzI0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDMyNFQxMzM1MTFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1kMmI4MTIyNDRkY2QzZjQ1YjBlYWNlMWQ4ZTJmNGM4YjRjYzhkYzVlOTNiNDljZTNmNTBiMzkxOTdmYzFmYTFmJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.f9_1FVImsqgkjFECPBIlzVYTHGkNL1wZEJThbEHf89U>

On 22/03/2025 9:16 AM, Eli Zaretskii wrote:
>> Date: Fri, 21 Mar 2025 18:46:30 +0100
>> Cc:77151 <at> debbugs.gnu.org
>> From: Mattias Roux<mattias <at> kojin.tech>
>>
>> As Mickey says when creating an issue:
>>
>>   > If you're experiencing one of the following problems:
>>   >
>>   > - Emacs crashes when you use `ligature.el`;
>>   > - Some ligations are visually garbled, cut off, or not rendering at all;
>>   > - No ligations are showing at all;
>>   > - Weird interactions with non-ligated characters around a ligated
>> character;
>>   >
>>   > Then it's very likely the issue is with **Emacs core**, and not
>> `ligature.el`. This package merely interacts
>>   > with the Emacs text shaping engine to configure your ligature
>> settings. It does not, on its own, do any sort
>>   > of ligation.
>>
>> That's why I created this bug report but since you asked I also created
>> an issue on the ligature repo:
>> https://github.com/mickeynp/ligature.el/issues/59
> Thanks.
>
> Looking at what happens, I'm not sure I see a bug in Emacs here.  For
> the ">>=" case (where you see no ligation), find-composition produces
> the following:
>
>    (267 270 [[#<font-object "-outline-Fira Code-regular-normal-normal-*-16-*-*-*-c-*-iso8859-1"> 62 62 61]
> 	    1
> 	    [0 0 62 1650 10 0 0 15 5 nil]
> 	    [1 1 62 1390 10 -8 8 15 5 nil]
> 	    [2 2 61 1578 10 2 8 15 5 nil]])
>
> Whereas for the ">>==" case, where you see ligation, it produces the
> following:
>
>    (467 471 [[#<font-object "-outline-Fira Code-regular-normal-normal-*-16-*-*-*-c-*-iso8859-1"> 62 62 61 61]
> 	    3
> 	    [0 0 62 1650 10 0 0 15 5 nil]
> 	    [1 1 62 1469 10 -7 10 15 5 nil]
> 	    [2 2 61 1456 10 0 10 15 5 nil]
> 	    [3 3 61 1455 10 0 8 15 5 nil]])
>
> (If you want to understand what these values mean, see the doc string
> of composition-get-gstring.)
>
> My conclusions from this are:
>
>    . Emacs does recognize both cases as composable sequences
>    . Emacs passes both sequences of characters to the shaping engine
>    . The differences on display are because the shaping engine returned
>      different sequences of font glyphs (the 4th element of the glyph
>      vector) in each case
>
> So the reason for this is probably in the font itself?  Maybe this
> should be taken up with the developers of the fonts?  I see a very
> similar behavior with Cascadia Code, so maybe these fonts assume or
> require something which the particular ligatures you used violate?

[Message part 2 (text/html, inline)]

Previous Next

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