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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Clément Pit-Claudel <address@hidden>
> 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?

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.

See, this is exactly part of the job that still awaits us: to figure
out the various use cases for displaying ligatures in a buffer, and
then provide the necessary user-facing features to adapt Emacs to each
use case.  The infrastructure for this already exists: it's the
auto-composition-mode and composition-function-table that underlies it
(although we may need to add something so that
composition-function-table could be modified on per-buffer basis), but
we lack an easy-to-use UI and customization features that will allow
users to use that machinery in practice.  See the TODFO item about
ligatures; volunteers are welcome to work on that.

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