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

[Vasilij Schneidermann <mail@vasilij.de>]

[-- Attachment #1: Type: text/plain, Size: 3359 bytes --]

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

Thanks for describing the problem in detail.  Out of curiosity, is this the
same reason why font fallback is handled on a per-script basis for most cases
and with carefully chosen ranges for emoji?  I see a similar problem there,
with updates being necessary for every Unicode release.

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

Given your previous explanation, a regex-based approach heuristic is the best
we can hope for then.  From what I understand the display engine uses a
rectangular grid, not unlike what terminal emulators do.  Are there any tricks
to steal from existing terminal emulators?  For example there is an open pull
request [1] for alacritty using Harfbuzz and FreeType for ligature support.

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

The greatest challenge I see with redesigning the display engine is supporting
textual terminals.  One alternative design would be using something akin to a
typesetting engine, like TeX's boxes and glue model or something from the roff
family (which is used successfully in terminal emulators for `man`).  Another
approach is to build upon a browser engine and use copious amounts of CSS and
JavaScript to build an editor.  Neither is known to be performant and power
efficient enough for continuous redisplay.  It's no wonder that custom designs
are used, for example in GUI toolkits.  Maybe that is the way forward?

Vasilij

[1]: https://patch-diff.githubusercontent.com/raw/alacritty/alacritty/pull/2677.patch

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]