Not all Cascadia Code ligatures are showing in emacs-27 latest on cygwin

[kmbgit]

Emacs-27.2 on my Cygwin installation was experiencing the "looping" behaviour described in issue 16 so I rebuilt following the instructions in that ticket with a few changes to give me the Cygwin-w32 variant...

git clone https://git.savannah.gnu.org/git/emacs.git
cd emacs
git checkout emacs-27
git checkout -b emacs-27-ligature
git cherry-pick -x fe903c5ab7354b97f80ecf1b01ca3ff1027be446

git log -n1 HEAD^
commit 0aa0410372dc9dbd251fec0ec71a28e88b9697ec (origin/emacs-27, emacs-27)
Author: Stephen Gildea <stepheng+emacs@gildea.com>
Date:   Wed Aug 25 17:39:26 2021 -0700

make configure
./configure --with-w32
make

I don't have use-package in this build (why not?!) so I created a ligature-setup.el file in my load-path alongside ligature.el (which I byte-compiled). I've used Option > Set Default Font... to select Cascadia Code. When I initially edit my setup file it looks like this (because I haven't run it yet) - none of the ligatures are showing, as you'd expect...

but after I M-x eval-buffer a lot of the ligatures fail to get swapped in (in particular "->" and "=>") ...

If I drop it into a C file in Visual Studio Code then things look right, so I guess the font is installed okay...

[kmbgit]

I had a play to come up with a smaller failing set, thinking the problem was to do with 2-character ligatures, but some containing "=", "<" or ">" work while others don't - in particular the ones containing just [<>][-=] in either order fail...

...but these combinations all work in VSCode and Notepad++ (the latter shown below). Most strange!

I noticed that my Emacs didn't compile with Cairo, despite having used ./configure --with-w32 --with-cairo from my Cygwin shell. Here's my config.log and config.status (I appended ".log" to the latter filename so I could attach it to this issue). But is this relevant or a red herring?

config.log config.status.log

[mickeynp]

I'm not sure if Cairo's needed on non-Linux platforms, to be honest - what does the build instructions for Windows suggest?

A likely scenario is that the rendering engine (whichever one Cygwin + the build options you chose uses) simply behaves differently than normal as most of them work but a select few of the ones you showed me do not. I take it you tried starting Emacs with one or two of the broken ones and confirmed that they still don't work? It would be useful to eliminate if the ligature package's automatic ligature generator somehow breaks for you on Cygwin-Emacs.

As for the no use-package: because the package does not work at all on Emacs 27.x I did not want to risk people installing it and crashing their Emacs unnecessarily. By forcing people to come here to install it they're at least likely to read the warnings first.

[kmbgit]

Hi Mickey,

No, I haven’t tried loading Emacs without the auto-ligature generator - I didn’t know I could!

I did wonder about “-“ causing problems in regular expressions because you have to escape it inside [] or it’s recognised as the “range” operator. But I don’t think “=“ has the same problem.

-- Kevin from my iPhone

On 27 Aug 2021, at 09:37, Mickey Petersen @.***> wrote:

 I'm not sure if Cairo's needed on non-Linux platforms, to be honest - what does the build instructions for Windows suggest?

A likely scenario is that the rendering engine (whichever one Cygwin + the build options you chose uses) simply behaves differently than normal as most of them work but a select few of the ones you showed me do not. I take it you tried starting Emacs with one or two of the broken ones and confirmed that they still don't work? It would be useful to eliminate if the ligature package's automatic ligature generator somehow breaks for you on Cygwin-Emacs.

As for the no use-package: because the package does not work at all on Emacs 27.x I did not want to risk people installing it and crashing their Emacs unnecessarily. By forcing people to come here to install it they're at least likely to read the warnings first.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[mickeynp]

Change the ligatures and enable just the errant few that don't work; restart Emacs and confirm if they still don't work. That way we can eliminate if there's a cygwin-specific issue with how the underlying ligation engine in Emacs behaves.

[mickeynp]

As for regexp in general: the system accommodates metacharacters, etc. just fine -- indeed the whole range of Cascadia code characters work fine with the defaults you see in the README. That's why I use myself running some somewhat-recent build from the tip of master.

[kmbgit]

Here's a minimal failing case - "<=" doesn't become the less-than-or-equals glyph...

...but if I do the same with "<~" then I get the squiggly arrow...

I'm running the latest available Cygwin64 on the latest Windows 10 Business (version 21H1 build 19043.1165), and I'm using Cascadia Code 2106.17 (okay, actually this time around I was using JetBrains Mono, and I've also had the same problem with Fira Code).

What platform are you testing on?

[mickeynp]

So there's clearly other issues at play than ligature.el. The squiggly arrow looks fine in your earlier Emacs screenshots also.

I test it on Linux as that is what I use. However most things generally run cross-platform without issue.

[kmbgit]

@mickeynp Since I'm running on Cygwin I'm using the Windows display driver, so perhaps that's contributing to the problem. I wondered whether it was a TTF vs OTF problem so I tried to uninstall CascadiaCode, only to discover it was installed twice - one being my user-local installation and the other an all-users as part of Microsoft Terminal - so I uninstalled that as well, then installed the OTF version.

It didn't help - I got exactly the same problem of <~ working but <- and <= refusing to play ball - but at least I tried. And when I reinstalled Microsoft Terminal, the version of CascadiaCode was 2106.017, same at the latest from GitHub, so there isn't a version issue either.

I get exactly the same problem with Fira Code and JetBrains Mono so it's something to do with those ligatures rather than the font, I think. Do <- and <= live in a different stylistic set to <~ ?

Not that I can see how ligature.el or even Emacs taps into stylistic sets, but I just discovered that they exist during a random google-wander around the internet! https://stackoverflow.com/questions/58965575/vscode-update-to-stylistic-sets-using-font-ligatures-with-fira-code

[mickeynp]

Emacs does not have direct support for stylistic sets. Instead ligature.el manually activates the ligatures you ask for. It sounds like a strange issue indeed.