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

[Eli Zaretskii <eliz@gnu.org>]

> From: Pip Cet <pipcet@gmail.com>
> Date: Sat, 23 May 2020 15:13:38 +0000
> Cc: cpitclaudel@gmail.com, alan@idiocy.org, emacs-devel@gnu.org
> 
> As I said, the problem I have is to get look-ahead working, which you
> think isn't a problem. I've got an idea for it, but it doesn't work
> (yet); my theory is the bidi.c code fails to keep its state in the
> iterator and can't deal with multiple parallel iterators.
> 
> > I could be wrong, though, so I'm looking
> > forward to see you present a series of patches that do support the
> > existing use cases and the ligatures as well, and don't cause any
> > slowdown in redisplay.
> 
> As I said, what's stopping me is the look-ahead problem, and in
> particular some code in bidi.c that doesn't play along well with
> look-ahead.

I don't think you understand the depth of the issue.  If we are going
to send large chunks of text to the shaping engine, then none of the
insane complexity of bidi.c makes sense; we should simply throw all of
it away and use a very different, batch-style reordering code, of the
kind you can find in the freebidi library.  The sole reason for
bidi.c's existence is to produce character positions in the _visual_
order, one position at a time, something that no other bidi-aware
editor does.

Moreover, not even the basic iteration, one level above bidi.c, where
we call get_next_display_element, then PRODUCE_GLYPHS, then
set_iterator_to_next -- not even that makes sense.  This basic loop
exists only because we examine characters one by one, switching from
buffer text to overlay or display strings, then back, as needed, and
applying faces as we go.  Doing this in large chunks calls for a very
different structure of the code, and very different separation into
layers.

This needs to be carefully designed in advance in a clean and
well-defined way, not lumped one patch upon another until it kinda
works...