emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ligatures (was: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywh


From: Eli Zaretskii
Subject: Re: Ligatures (was: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY))
Date: Sat, 23 May 2020 09:47:52 +0300

> Cc: address@hidden, address@hidden, address@hidden
> From: Clément Pit-Claudel <address@hidden>
> Date: Fri, 22 May 2020 16:02:22 -0400
> 
> > 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).

And yet people do use that, and like it, and swear by it.  So having
something similar without using explicit font glyphs is a kind of
progress, isn't it?  It certainly doesn't sound like a regression to
me.

A more thorough solution is outlined in TODO, and I hope at some point
someone will start working on that.  Until now, we are just talking.

> 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.

Emacs doesn't need a special list for each font.  I already said that
several times.  Please look at some examples of composition rules we
already have, for example the Arabic rules at the very end of
misc-lang.el.  Do you see any fonts mentioned there?  These rules work
with any font that supports Arabic.

> Each font supports a different set of symbol ligatures, and so the list for 
> each font will be different.

No, the list doesn't need to be different.

> 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.

I'm not yet sure this is indeed so.  I didn't see any reference which
implies that any combination of 26 ASCII letters could become a
ligature.  And even if this is what happens in some fonts, we still
need to decide whether it makes sense to produce such arbitrary
ligatures in Emacs, for supporting use cases that are relevant to us.
This is a discussion that didn't yet happen.  It is quite possible
that in practice the list of ligatures we want to support is not very
long.  E.g., the list in
https://github.com/tonsky/FiraCode/wiki/Emacs-instructions is not
long, and I doubt manu additions to it will ever make sense for us.

In any case, the superset of all the possible ligatures does exist,
even if it is very large, because ligatures are generally limited to a
small number of characters.

And finally, if a given font doesn't support some ligature, the
original characters will be displayed "normally", so nothing is lost,
and there's no need to tune the list of ligatures to each and every
font.  I said that as well several times already.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]