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

Previous Next

Package: emacs;

Reported by: Pip Cet <pipcet <at> gmail.com>

Date: Fri, 22 May 2020 12:51:02 UTC

Severity: normal

Found in version 28.0.50

Done: Pip Cet <pipcet <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 41454 <at> debbugs.gnu.org
Subject: bug#41454: 28.0.50; [".+" 0 font-shape-gstring] composition rule breaks paren highlighting
Date: Fri, 22 May 2020 16:01:24 +0300
> From: Pip Cet <pipcet <at> 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.

Could be, because it's a very unusual thing to do.

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

I think this is expected, since you told Emacs all those characters
are a single grapheme cluster.

The regexps in composition-function-table should match only characters
that are supposed to be composed.




This bug report was last modified 4 years and 355 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.