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

[GNU bug Tracking System]

Your message dated Wed, 03 Jun 2020 07:50:45 +0000
with message-id <87v9k87fl6.fsf@gmail.com>
and subject line Re: bug#41454: 28.0.50; [".+" 0 font-shape-gstring] 
composition rule breaks paren highlighting
has caused the debbugs.gnu.org bug report #41454,
regarding 28.0.50; [".+" 0 font-shape-gstring] composition rule breaks paren 
highlighting
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
41454: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=41454
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: 28.0.50; [".+" 0 font-shape-gstring] composition rule breaks paren highlighting Date: Fri, 22 May 2020 12:50:13 +0000

...and other things. It's probably a case of "if it hurts, don't do that".

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

paren.png
Description: PNG image

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#41454: 28.0.50; [".+" 0 font-shape-gstring] composition rule breaks paren highlighting
>
>
>
>
> Date: 
>
> Wed, 03 Jun 2020 07:50:45 +0000
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13)
>
>
>
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > LGTM, thanks.
>
> Pushed, closing this bug.
>
>
> --- End Message ---