Kitty: Some ligatures not correct in mysterious circumstances

[NAlexPear]

Running 0.7.1, I just noticed a regression in how two hyphens (--) are displayed. It appears 0.7.1 attempts (and fails) to treat the two hyphens as a ligature when using a ligature-enabled font (in my case Fira Code). Some screenshots:

0.6.x

0.7.1

[kovidgoyal]

Works for me, with

kitty --config NONE -o "font_family=Fira Code" sh -c "echo '--'; read"

[NAlexPear]

Odd, this must have been a bug that started somewhere else along the pipeline... sorry for the clutter, and thanks for taking a look!

[wbthomason]

@NAlexPear For what it's worth, I am also seeing this behavior in Kitty with Fira Code, as well as oddities in rendering a few other ligatures. It is intermittent, and I haven't yet figured out what makes a ligature render correctly/incorrectly.

[kovidgoyal]

If you can figure out some steps to reproduce it, I will be most interested.

[wbthomason]

The other two ligatures I have noticed this behavior with (in addition to --) are .. and */ (though I haven't tested the full set of ligatures to see if there are other regressions. I'm using Fish in tmux in Kitty. I see these regressed renderings in plain Fish and in Neovim (all I've tested so far).

Interestingly, after running the example @kovidgoyal gave above for --, I can no longer seem to reproduce that particular issue. The same seems to be true for .. when I run the same example with that ligature instead of --, but trying this trick for */ seems to have no effect.

Further, even before running that example, sometimes the ligatures would render correctly, and sometimes they would fail, with no changes to configuration in between.

[kovidgoyal]

That's just strange, there is no font rendering data persisted between invocations of kitty. Incidentally what OS are you on?

[kovidgoyal]

Also is you have some set of steps to reproduce the bad rendering, you can use the --dump-bytes option to create a dump that I can use to try to reproduce.

[wbthomason]

I agree, it is very strange. I am on Arch Linux, fully updated. If I can ever figure out a consistent way to reproduce the issue, I'll report the steps and dump here.

[NAlexPear]

@wbthomason I'm on Arch as well, and haven't been able to reproduce since running that command from @kovidgoyal. Maybe it's an Arch-specific font caching issue?

[kovidgoyal]

I'm on Arch too, but I have not seen it.

[LeonardKoenig]

Got similar unpredictable results here, but mostly they can be triggered in ViM, as if the shell line-editor wouldn't be complex enough to trigger it often enough.

I'll try some bisecting

[kovidgoyal]

If you can trigger it use --dump-bytes and post the dump, that should allow me to reproduce it.

[LeonardKoenig]

The regressing commit is 1ae7ae4a1d9eb2e8d2dcce155d7f1f5245a715d3, which kind-of makes sense.

A dump of kitty at exactly this revision reproducing the bug is attached, what I did:

$ python . --dump-bytes=/tmp/kitty.txt

Then in the new terminal window:

$ vim
-- --\ESC:q!^D

Everything was displayed correctly until the third '-' was typed (ie. the '' after the first two consecutive '-' did not trigger the error).

[kovidgoyal]

OK I'll take a look when I have a moment.