Re: Ligatures

[Pip Cet]

On Tue, May 19, 2020 at 3:36 PM Eli Zaretskii <address@hidden> wrote:
> > From: Pip Cet <address@hidden>
> > Date: Tue, 19 May 2020 15:11:27 +0000
> > Cc: address@hidden, address@hidden
> >
> > On Tue, May 19, 2020 at 2:52 PM Eli Zaretskii <address@hidden> wrote:
> > > Btw, there's one subtle issue that will need to be resolved if we are
> > > to have this feature of "sub-glyph" cursor movement inside composed
> > > characters.  The way we currently display the default block cursor is
> > > by simply redrawing the glyph at point in reverse video.  So we don't
> > > have a way of displaying a cursor that "covers" only part of a glyph.
> >
> > I thought that was what glyph_row->clip was for.
>
> We could use that, but that's not the main problem.

Sorry, I genuinely don't understand what the problem is. draw_glyphs
is called by draw_phys_cursor_glyph, so all we need is a line or two
of extra code in draw_phys_cursor_glyphs to set row->clip to the
rectangle surrounding the subglyph the cursor is on. No further change
of the display engine is required for that, is it?

> The problem is that we need to change how the cursor is drawn, from
> the control flow POV.

That's a separate thing that, yes, we need to do. Because optimizing
for TTYs is no longer appropriate. But I don't see why we need to
perform this large change before performing the little one that makes
things work for subglyphs.

> We'd need to audit the code and see that the
> information required for drawing the cursor is available when we are
> drawing the text.  And then there's the popular use case where nothing
> changes except the cursor position, in which case no text is redrawn
> at all.

Except for the glyphs the cursor is on, right? Those are redrawn by
draw_phys_cursor_glyph, or am I missing something here?

> > > To make this happen, we'd probably need to draw the cursor as part of
> > > drawing the glyph foreground and/or background, which is against the
> >
> > I believe that's a change we should make anyway: late cursor drawing
> > makes sense on TTYs with physical cursors, but on GUI backends, we
> > should simply use a special face for drawing the struct glyph a cursor
> > is on, IMHO.
>
> It cannot be a single face, because the "thing under cursor" can be
> anything, and can have different colors.

Agreed.

> We will need to merge faces,
> which is slower than the current simple but effective method, which
> completely sidesteps the issue.

I believe performance concerns are an entirely different subject (put
briefly, my opinion is that we've painted ourselves into a corner by
micro-optimizing fast loops over an essentially inefficient basic
design).

> in any case, using a face doesn't solve the main problem, as we'd
> still need to draw the glyph with partial colors.

Which we can do by setting glyph_row->clip? I don't see how there's
any problem here at all.

Again, I see three totally separate problems here:

1. draw a box cursor over a partial glyph
2. improve the display engine to handle cursor(s) like other
highlighting on graphical terminals
3. identify and counteract actual performance problems in the redisplay engine

I still don't see how (1) depends on (2), and I think I disagree with
you on the subject of (3), because I think we need to fix the design
first, moving a lot of C code out to Lisp, then see where things
actually chafe and maybe move some special code back to C.