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

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Fri, 22 May 2020 12:50:13 +0000
> 
> There seems to be a general problem using such regexps in the
> composition-function-table.
> 
> If I evaluate this in emacs -Q (by placing point after it and hitting C-x C-e)
> 
> (custom-set-faces
>  '(default ((t (:family "Libertinus Serif" :height 330)))))
> (set-char-table-range composition-function-table t '([".+" 0
> font-shape-gstring]))
> 
> the font correctly changes to a very large Libertinus font. I then hit
> C-b C-d ) and the entire last line is highlighted, not just the
> opening parenthesis. After the blink delay is over, the opening
> parenthesis and the "s" following it are unhighlighted, but the rest
> of the line is not. It stays like that permanently (screenshot
> attached).

This is unrelated to the fact that characters to be composed are
specified with regexps.  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.
It could even be that this is a side effect of recent changes in that
area of the display engine that fixed much more serious problems with
compositions (see bug#28312 and commit c42c4e9c5 which fixed it).  I
couldn't verify that this problem doesn't appear in Emacs 26 or older,
because Emacs only recently learned not to infloop or crash when
attempting to compose pure-ASCII text.