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

[Eli Zaretskii]

> Date: Sat, 23 May 2020 10:05:21 +0200
> CC: address@hidden,address@hidden
> From: Vasilij Schneidermann <address@hidden>
> 
> Adding ta as new signature to a font is merely an example, any font update 
> may include new supported ligatures and Emacs would need to play catch-up 
> with them whenever that happens. This is undesirable from the user 
> perspective, it's suboptimal to tweak font settings every time there's a 
> significant update, time better spent on productive work.

I agree.

> I do not understand why there's a need for this kind of compromise when 
> everything else supporting ligatures does support them fully, no matter the 
> font and its ligature list. What is the real reason for not considering 
> unconditional support? Is it technical difficulties of integration into 
> Emacs? Fear of performance issues? Need of a whitelist system?

The reason is how the current Emacs display engine is designed: it
cannot pass large substrings of buffer text to the shaping engine
without incurring performance penalties and/or disrupting the way the
layout decisions, as currently designed, work.  the current design of
the display engine is that we examine the stuff to be displayed one
grapheme cluster at a time, and make the layout decisions after each
grapheme cluster's metrics is produced.  Unless someone begins working
on a new design of the Emacs display, I see no good way for overcoming
these problems, based on what I know about the display code.

> Please spell out why you insist on enumerating every possible ligature and 
> dismiss alternative approaches. I hope there to be a compelling reason for 
> Emacs to not being  a first-class citizen when it comes to font support.

I didn't see any alternative approaches described in enough detail to
make them viable candidates.  Therefore, I don't think I dismissed any
proposal.  All I did in this very long thread is try to patiently
explain how the current display code handles character compositions,
and why it requires us to provide up front the regular expressions for
character sequences to be composed.

Of course, it's possible that I'm missing something in the current
display code, which could luckily allow us to support any ligature
made up from any number of characters without any significant design
changes.  So please by all means study the current code, see if
something like that is possible, describe such a possible solution,
and I'll gladly admit my mistake.  I don't claim a 110% understanding
of all the subtleties of the current code, so it is perfectly possible
that I'm missing something.  I don't think it is good for Emacs to
have just one person who knows these details, especially if that
person is myself.  We need to enlarge the circle of our experts on
this, and then perhaps a practical solution could present itself.
Although I'm skeptical, to tell the truth.

If I _am_ right, and the complete solution is impossible, we could, of
course decide that partial solutions based on heuristics are not good
enough for us, and wait for the redesign of the display code.  I hope
we will not do that, because IMO partial solutions that satisfy 80% of
the needs are much better than no solutions.  That is why I described
how this stuff could work under the current limitations, albeit
without supporting every possible use case.  Eventually, this is
something the community should decide.