>>= is not rendered

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?

Review the linked Emacs bug report and compare the >>= and >>== cases described there. Start with the composition-get-gstring documentation and the reported shaping results; done means determining whether Fira Code requires a font-side change or whether the behavior is expected.