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

[Eli Zaretskii <eliz@gnu.org>]

> From: Pip Cet <pipcet@gmail.com>
> Date: Wed, 27 May 2020 18:42:07 +0000
> Cc: emacs-devel@gnu.org
> 
> > What did you compare, exactly?  On the one hand, the code you posted
> > here, which took 128 characters around each character to be displayed?
> 
> No. Not anything like that code.

Then your numbers cannot be meaningfully reasoned about, because no
one knows what you did.

> There's no reason to believe the composite.c regexp design will
> perform adequately. It doesn't.

I guess in your eyes only your code performs adequately.

Sorry, this means any further discussion with you on these matters is
futile.  I regret to have wasted so much time trying to explain how
this stuff works.  I will try to be smarter next time when you ask
some question.

> (It's not enough. Open emacs -Q etc/HELLO, place point on the lam in
> "aleikum", and hit control-space. The shape changes to something
> incorrect.)

A known limitation of our handling of faces in conjunction with
character composition.  Finding the reason is left as an exercise.

> > >  - "entering" glyphs, instead of treating them as atomic
> >
> > Why is that needed?  A ligature is a single display entity, that's why
> > fonts ligate.
> 
> "ffi" is not. When I enter "official" C-a C-f C-f, point MUST be on
> the second f.

That doesn't require producing separate glyphs.

> > It doesn't and it shouldn't!  Text of display strings and overlay
> > strings is completely isolated from buffer text, and is even
> > bidi-reordered independently.  This is by design.
> 
> Unacceptable design for my use case, then.

This is the design of the Emacs display engine.  If it doesn't fit
your case, your case cannot be had in Emacs without rewriting the
display code.

> No, it wouldn't be. If two letters appear with no intervening space,
> they need to be kerned and ligated if appropriate, no matter where
> they come from. If people want a ZWNJ, that's perfectly available to
> them.

That's not what display and overlay strings are for in Emacs.

> > Fixed limits and fixed strings are two different things.  You can
> > match strings of many different lengths up to a limit.
> 
> Which effectively means you can match strings of that limited length.

Except that there's no limit, of course.

> > The 3 previous characters are rarely needed, certainly not for English
> > ligatures, because you can detect the sequence by the first character.
> 
> Precisely the same argument applies to my 16-character limit. A script
> in which a glyph depends on something happening 16 codepoints onwards,
> or back, is extremely unlikely.

You are wrong.  Please read this:

  https://lists.freedesktop.org/archives/harfbuzz/2020-May/007517.html
  https://lists.freedesktop.org/archives/harfbuzz/2020-May/007521.html

This is what is needed for doing ligatures The Right Way.  Collecting
an arbitrary number of codepoint doesn't cut it.

And in any case, I was talking about the need to look _backward_,
i.e. when the character that triggers the composition is not the first
one in the sequence of the characters to be composed.  This is usually
needed as an optimization: if you have 2-character sequences where the
second character is one of a much smaller set than the first, then
using the second character as an anchor will use up less memory when
you set up composition-function-table.  A case in point is a base
character and a diacritic.

How many characters you need _forward_ is an entirely different issue.

> It needs to be modified, significantly, to support entering glyphs, to
> support kerning, and to support things like ligating across a buffer
> text / display string boundary.

Two of these are not needed or are outright wrong, and the third
doesn't need anything, the shaper already does that with any text you
pass through it.

> But, seriously, you're still willing to argue that point shouldn't be
> able to enter the "ffi" glyph? Not even if the user wants it? Because
> if so, I suggest we interrupt the discussion here.

See above.  I indeed see no reason to continue this discussion, as
evidently any progress here is impossible with your attitude in place.