Subject: Re: bug#41454: 28.0.50; [".+" 0 font-shape-gstring] composition rule breaks paren highlighting

From: Pip Cet <[email-masked]>
Date: Sun, 31 May 2020 19:58:09 +0000

On Sun, May 31, 2020 at 6:01 PM Eli Zaretskii <[email-masked]> wrote:
> > Date: Sun, 31 May 2020 20:50:07 +0300
> > From: Eli Zaretskii <[email-masked]>
> > Cc: [email-masked]
> >
> > The problem is that the entire sequence of characters that matches
> > the regexp is passed to the shaper, and the result is stored as a
> > single composition.  And we have special code in the display engine
> > not to break sequences of potentially-composed characters when
> > handling faces (see compute_stop_pos).  So I think there might be
> > some bug there which shows when a composition comprises more than a
> > single grapheme cluster, and some face is applied to them.
>
> On second thought, I'm not sure this is the right place to look at.
> It could be fill_gstring_glyph_string and BUILD_GSTRING_GLYPH_STRING
> instead (and the respective *term.c display functions).

Thanks for the hint! You were absolutely correct.
From c1d4778001567f7dfc7825b69193089ec69897bb Mon Sep 17 00:00:00 2001
From: Pip Cet <[email-masked]>
Date: Sun, 31 May 2020 19:55:48 +0000
Subject: [PATCH] Don't get confused by mid-gstring face changes (bug#41454)

* src/xdisp.c (fill_gstring_glyph_string): Don't extend the glyph
string past face changes.
---
 src/xdisp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/xdisp.c b/src/xdisp.c
index db0ec68315..989958fa11 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -27698,6 +27698,7 @@ fill_gstring_glyph_string (struct glyph_string *s, int face_id,
   while (glyph < last
 	 && glyph->u.cmp.automatic
 	 && glyph->u.cmp.id == s->cmp_id
+	 && glyph->face_id == face_id
 	 && s->cmp_to == glyph->slice.cmp.from)
     {
       s->width += glyph->pixel_width;
-- 
2.27.0.rc0