emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ligatures


From: Eli Zaretskii
Subject: Re: Ligatures
Date: Tue, 19 May 2020 20:00:02 +0300

> From: Pip Cet <address@hidden>
> Date: Tue, 19 May 2020 16:16:53 +0000
> Cc: address@hidden, address@hidden
> 
> Sorry, I genuinely don't understand what the problem is.

There's no need to argue.  There's a TODO item regarding ligature
support, and I just updated it with the ideas from this discussion.
You, or anyone else, are welcome to work on some or all of that.  I
think good ligature support in Emacs is long overdue; that is one of
the reasons we added HarfBuzz support and are steadily moving towards
making it the default font backend.  Any advances in the direction of
letting Emacs use advanced features of modern fonts are welcome.

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

Feel free to ignore me.  I may be completely wrong about this.  Please
disregard what I said and just code away what you think is needed to
implement this.

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

Basically, yes, draw_phys_cursor_glyph.  But there are other functions
related to that, and which ones need to be changed for this "partial"
cursor drawing to work, I really don't know/remember, sorry.  You need
to read the code.

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

The current design is that faces are realized lazily and cached for
subsequent use, because realizing a face is expensive.  It makes no
sense to realize a face each time we blink the cursor.  No matter what
you think about the current design, code which does unnecessary
calculations is bad code.  Gerd Moellmann, which designed and
implemented the current display engine, isn't stupid or incompetent,
quite the contrary.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]