Re: Ligatures (was: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY))

["Clément Pit-Claudel" <cpitclaudel@gmail.com>]

On 22/05/2020 07.44, Eli Zaretskii wrote:
>> Cc: alan@idiocy.org, emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 21 May 2020 16:51:47 -0400
>>
>> On 21/05/2020 15.08, Eli Zaretskii wrote:
>>> That would prevent Emacs from controlling what is and what isn't
>>> composed, leaving the shaper in charge.  We currently allow Lisp to
>>> control that via composition-function-table, which provides a regexp
>>> that text around a character must match in order for the matching
>>> substring to be passed to the shaper.  We never call the shaper unless
>>> composition-function-table tells us to do so.
>>
>> Does this mean that for each font we need to re-encode the font's logic for deciding whether to use a ligature?
> 
> I don't think so, but I'm not yet sure I understand all the details of
> the use cases you have in mind.  See also my responses to Pip Cet:
> perhaps they answer also your questions here.
> 
>> Some concrete examples: in Iosevka (*, (**, (***, (**** etc are all displayed with the * character vertically centered relative to the (, but a lone * is not centered. In Fira Code, punctuation is context-aware, so the "+" in "A + B" is not the same as the "+" in "a + b".  In both of these faces, arrows can be of any length, and in Fira Code you can even mix and match them (see https://raw.githubusercontent.com/tonsky/FiraCode/master/extras/arrows.png). 
> 
> How do you solve this in prettify-symbols-mode?

You don't, which is unfortunate.  prettify-symbols-mode was extremely cool a few years ago when fonts with programming ligatures were mostly unheard of, and it's still extremely nice for things like prettifying lambda in λ, but for things like turning ascii arrows into pretty arrows it lags behind the more recent ligature stuff.

> In general, I envision that people would use the font they find
> acceptable for the ligatures they want/need in each mode or buffer
> where they need that.  If for some reason different fonts could
> determine which ligatures you do NOT want to see, then I guess we will
> have to provide some easy-to-use UI for that, which would manipulate
> the relevant data structures under the hood.  Alternatively each font
> could require a separate composition function to go with it.

It would be weird for Emacs to be the only program that requires re-encoding the entire ligature logic of each font it attempts to use.  Different fonts offer different ligatures, and if I want to select a subset the font itself provides variants that let me do this.  Meanwhile, I hope that we can make Emacs act like browsers or other editors in that if I select a font it will just, by default, use the ligatures that this font provides according to the logic embedded in the font.

>> The documentation of Fira Code does recommend composition-function-table here: https://github.com/tonsky/FiraCode/wiki/Emacs-instructions, but it seems like a lot of extra work for each font, isn't it?
> 
> That's for static compositions, not for automatic compositions.  I was
> talking about the latter, and consider the former to be a
> semi-obsolete feature that we should eventually remove.

I see.  I need to read up on the difference.