On Sun, Aug 31, 2025 at 18:35 Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: 79285@debbugs.gnu.org
> > Date: Sun, 31 Aug 2025 12:25:32 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> >
> > If I'm right, then we will need to make changes in display-engine
> > functions like composition_compute_stop_pos, composition_reseat_it,
> > find_composition, and others, to force the text which has such a face
> > attribute to be handed to HarfBuzz for shaping.  An alternative is to
> > require that use of this face attribute needs special setup of
> > composition-function-table, but that is IMO worse because it will slow
> > down display of the relevant characters even if they don't have the
> > face with this attribute.
>
> Or maybe it will be enough to make the change in
> get_glyph_face_and_encoding, as the etc/TODO item suggests:
>
>   instead of calling the 'encode_char' method of the font driver, we
>   should invoke the 'shape' method
>
> But this will only work if the effect of the relevant font features is
> per-character, i.e. HarfBuzz doesn't need to see the entire word to
> shape the characters according to the requested feature(s).  Do you
> happen to know if all the features that are relevant for us can be
> applied on a character-by-character basis?


I was diving into a bit more detail of how text is rendered in Emacs. If I
understand correctly the your suggestion is bypassing the composite.el and
constructing the glyph string directly in xdisp.c and pass it to all kinds
of shape function in different backend directly?

I’d need to wrap my head around the display engine first to have more
constructive discussion. A bit more direction from you on what to look for
will be very helpful.