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

[Clément Pit-Claudel]

On 22/05/2020 15.44, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden, address@hidden
>> From: Clément Pit-Claudel <address@hidden>
>> Date: Fri, 22 May 2020 15:33:59 -0400
>>
>>>> But then how do you handle symbol ligatures?
>>>
>>> By using suitable regular expressions.  E.g., you could take the list
>>> of ligatures in that FiraCode site and convert them into a regexp or a
>>> set of regexps.
>>
>> Thanks.  I don't understand why we need to do this
> 
> I'm not sure I follow.  Do you understand why
> https://github.com/tonsky/FiraCode/wiki/Emacs-instructions includes a
> long list of strings to be replaced with ligatures?  

Yes, I do understand: that's because Emacs' ligature support is currently 
weaker than other editors, and so you need to jump through hoops to use Fira 
Code.  These hoops include telling Emacs what sequences to turn into ligatures. 
 This problem is specific to Emacs: in other text editors, you just pick the 
font, and all supported ligatures are used.  Importantly, the instructions on 
that page are a poor workaround that doesn't give you all the features of Fira 
Code (I don't mean that we couldn't support all of them, as I don't know if 
that true currently.  I just mean that the page shouldn't be understood as 
providing full support for Fira Code in Emacs).

That's why Emacs is in the fairly short list of "Doesn't work" editors, I think.

> If so, why don't
> you understand the reason we need to specify similar things when we
> use automatic compositions?

What I don't understand is what it is about Emacs that means that we need 
special lists of regexps for each new font, while other editors don't need them.

> And who is "we" in this case?  Users of these features indeed
> shouldn't need to mess with these long lists of character sequences,
> but why is it a problem if "we" the Emacs developers provide data
> bases of such sequences in advance, which user-facing features could
> use, hiding them behind much easier UI?

We can't provide these data bases in advance, I think.  Each font supports a 
different set of symbol ligatures, and so the list for each font will be 
different.

>> it seems surprising that we'll need extra Emacs-specific work for each and 
>> every font that includes ligatures).
> 
> I don't understand how you got to this conclusion.  This is true for
> prettify-symbols-mode, but that's exactly why I don't like that
> implementation, and why I think automatic compositions are a better
> way to go.  And for automatic compositions we didn't yet decide that
> any user-level action is needed when you switch to another font, we
> are still discussing what is involved.  Up front, I don't yet see why
> such font-specific adjustment would be required from users.

Each font offers a different set of symbol ligatures: there is no common 
superset that covers all fonts, except the ".+" regexp that Pip posted earlier. 
 From earlier messages, I understood that we need to specify which character 
sequences to ligate.  So, I conclude that we'll need new work every time a new 
font comes out, or the ligatures in a font change (every time Fira Code is 
updated, for example).  Since other editors don't need that work, I wonder why 
it's needed in Emacs.

Sorry if I misunderstood something; I don't want to waste anyone's time.

Clément.