>>= is not rendered

[mattiasdrp]

Hi,

I filled a bug report on emacs debug about >>= not rendering but they told me that it looks like the bug comes from the font:

Here's the bug report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77151

>>=

>>=:

Is there something I need to do or is this a bug?

---

Here's the full conversation from the bug report:

Question:

Hi,

From emacs -Q you can evaluate the following code:

(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))
(package-initialize)

(set-face-font 'default "Fira Code")

(use-package ligature
:ensure t
:config
;; Enable the "www" ligature in every possible major mode
(ligature-set-ligatures 't '("www"))
;; Enable traditional ligature support in eww-mode, if the
;; `variable-pitch' face supports it
(ligature-set-ligatures 'eww-mode '("ff" "fi" "ffi"))
;; Enable all Fira Code ligatures in programming modes
(ligature-set-ligatures 'prog-mode '((">" (rx (+ (or ">" "<" "|" "/" ":" 
"=" "-"))))))
;; Enables ligature checks globally in all buffers. You can also do it
;; per mode with `ligature-mode'.
(global-ligature-mode t)
(message "`ligature' loaded"))

Now, if you open /tmp/test.el and write >>=, it won't be rendered, but if you add any character (like = or :) it will.

I also tested it with emacs 30.1

Answer:

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?

[tonsky]

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

[ndokos]

"Literally everywhere else" is a slight exaggeration. E.g. Firefox on Fedora 40 does not render the ligature, whereas Google Chrome on the same platform does. So Emacs is not the only place where the ligature is not rendered. OTOH, Firefox on Windows 11 does render it correctly (as do Chrome and Edge).

[tonsky]

Does Firefox on Fedora 40 render other ligatures in Fira Code?

[ndokos]

I don't know. All I know is that I clicked on the link above and I did not see any ligatures rendered (and I tried modifying it with additional = signs: those were not rendered properly either). Trying the same thing on Chrome worked with no problems.

[tonsky]

So it looks like a Firefox on Fedora 40 problem, doesn’t it?

[mattiasdrp]

Eli dug deeper and here's his report (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77151#22):

So I wanted to see if this is an Emacs problem or not. I did two things:

. Tried the same in the Command Prompt of Windows 11, which on my system uses Cascadia Code font, which also supports these ligatures. Lo and behold, it behaves the same: ">>=" produces something that doesn't look like a ligature (but if I watch carefully, I do see that when I type the second ">", the two ">>" together look differently than a single ">", so it's a different font glyph -- exactly like I saw in the output of find-composition). And if I type ">>==", I get the ligature, exactly like in Emacs.

. Invoked hb-view, the standalone shaping program that is part of HarfBuzz. I invoked it like this:

 hb-view FiraCode-Regular.ttf --text=">>=" -o lig3.png -O png

The resulting file lg3.png is attached. You will see that it looks exactly like the "no-ligature" result in Emacs. Then I tried the same with the 4-character sequence:

 hb-view FiraCode-Regular.ttf --text=">>==" -o lig4.png -O png

The file lig4.png is also attached. You will see that it shows the ligature, identical to what Emacs produces with these 4 characters.

So at this point I see no evidence that Emacs does anything wrong, since the standalone HarfBuzz shaping program produces the same output as what Emacs shows. I wonder what am I missing, if indeed "every other program does show the ligature" in the ">>=" case with the same fonts. Maybe the font developers could tell more about what other applications do, since AFAIK they all use HarfBuzz. Maybe they use some optional features of the shaping? (I tried to turn on kerning, it didn't help.)

[tonsky]

I’ll re-check. Which exact version of the font are you using? Can you attach a font file here?

[mattiasdrp]

I'm using the last released version

FiraCode.tar.gz

[tonsky]

Thank you for your patience. I can confirm this is an issue in the font indeed. Will fix in the next release

[mattiasdrp]

Thanks! Glad you were able to find the bug!