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

[Eli Zaretskii]

> From: Pip Cet <address@hidden>
> Date: Sat, 23 May 2020 22:38:18 +0000
> Cc: address@hidden, address@hidden, address@hidden
> 
> On Sat, May 23, 2020 at 4:34 PM Eli Zaretskii <address@hidden> wrote:
> > > From: Pip Cet <address@hidden>
> > > Date: Sat, 23 May 2020 15:13:38 +0000
> > > Cc: address@hidden, address@hidden, address@hidden
> > > Because what the current layout code does by default is to break
> > > along any glyph boundary, and I don't see how that's broken in any
> > > way.
> >
> > The code assumes that breaking on some glyph leaves the buffer
> > iterator ('struct it') in a state that we can simply continue to the
> > next buffer position.
> 
> Yes. I see no reason to change that.
> 
> > But if you already picked up several characters
> > via look-ahead, that is not true, and you will have to return back
> > several character positions, in order to continue on the next screen
> > line.
> 
> You're describing why look-ahead is difficult: a while ago, you
> appeared to be saying it wasn't. This confuses me.
> 
> Obviously, when I say "look-ahead", I mean receiving the next display
> elements an iterator would produce if it were actually advanced,
> without advancing it.

That's not what you said earlier:

> > > > > You write: "(b) is not really feasible without redesigning the entire
> > > > > Emacs display engine". I don't see how that's true at all. All we need
> > > > > is some limited look-ahead.
> > > >
> > > > We already have look-ahead: that's what the regexp part of the
> > > > composition rules are about.  That is not the crucial problem.
> > >
> > > But it's the only problem I see!
> >
> > Then maybe I don't understand what you mean by look-ahead.  Is that
> > the decision how to choose those 32 characters of "context"?
> 
> Yes.

Here you said that look-ahead means how to _choose_ the context.  Now
you are saying something very different: that look-ahead is how to
advance the iterator without advancing it.  It's a small wonder we are
going in circles when the same term is used for two very different
things.

> > If we want the shaper to handle all the text we display,
> 
> Do we? A while back you said Lisp control over compositions was an
> important feature, and I'm inclined to think we shouldn't break the
> existing composition code.
> 
> > we should go all the way and do it for any text, ASCII, non-ASCII,
> > symbols, emoji, everything.
> 
> Are you suggesting I'm somehow limiting myself to ASCII? Let me assure
> you that's not the case.

Then I really don't understand what problem are you trying to solve.

Let's try again from the beginning: which parts of the code that
implements automatic compositions are you trying to avoid, and why?
Is that the part that identifies the "context" via regular
expressions?  If so, then this problem needs to be solved by some
alternative; using an arbitrary chosen fixed number of characters is
not suitable for production.  You haven't yet shown any viable
alternative.

Assuming that the alternative for selecting the "context" is found,
and composite.c is augmented to apply it instead of the regexps, why
not use the rest of the automatic composition code to produce the
glyphs and display them?  The code which does that exists and works,
and is tested by years of use.  It already solves the problems of
look-ahead, of wrapping long lines, and others, including (but not
limited to) the dreaded bidi thing.  Why reinvent that wheel when we
already have it, and it works well?

> > and on top of that solve only a small part of the
> > underlying problem.
> 
> Ligatures and kerning (right now, for LTR text). Is that a small
> problem because of the lack of RTL support?

Yes, of course.  An acceptable solution should support any text Emacs
supports.  What's more, we already have the code which implements all
that, so I don't understand why you want to bypass it.  Please
explain.