bug#56188: 28.1; blink-matching-paren works wrong with non-ASCII parentheses

bug#56188: 28.1; blink-matching-paren works wrong with non-ASCII parentheses

[awrhygty]

In emacs-lisp-mode or lisp-intraction-mode, insert following text.
  ;;abc def【ghi】
  ;;【123】456 789

When the cursor is before 【ghi】, highlighting is not done.
When the cursor is after  【ghi】, 'd' is highlighted.
when the cursor is before 【123】, '6' is highlighted.
when the cursor is after  【123】, highlighting is not done.


In GNU Emacs 28.1 (build 2, x86_64-w64-mingw32)
 of 2022-04-22 built on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19044
System Description: Microsoft Windows 10 Pro (v10.0.2009.19044.1766)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation
 --without-compress-install CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
term/bobcat japan-util iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp
disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads w32notify
w32 lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 60763 6601)
 (symbols 48 6993 1)
 (strings 32 20757 1470)
 (string-bytes 1 671948)
 (vectors 16 14875)
 (vector-slots 8 354131 12574)
 (floats 8 24 271)
 (intervals 56 431 17)
 (buffers 992 10))

bug#56188: 28.1; blink-matching-paren works wrong with non-ASCII parentheses

[Eli Zaretskii]

> From: awrhygty@outlook.com
> Date: Fri, 24 Jun 2022 22:08:25 +0900
> 
> 
> In emacs-lisp-mode or lisp-intraction-mode, insert following text.
>   ;;abc def【ghi】
>   ;;【123】456 789
> 
> When the cursor is before 【ghi】, highlighting is not done.
> When the cursor is after  【ghi】, 'd' is highlighted.
> when the cursor is before 【123】, '6' is highlighted.
> when the cursor is after  【123】, highlighting is not done.

I cannot reproduce this.  I suspect that the problem could be related
to the font you use there for the U+3011 RIGHT BLACK LENTICULAR
BRACKET character.  Is this in "emacs -Q"?

bug#56188: 28.1; blink-matching-paren works wrong with non-ASCII parentheses

[Eli Zaretskii]

> Cc: 56188@debbugs.gnu.org
> Date: Fri, 24 Jun 2022 16:38:54 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: awrhygty@outlook.com
> > Date: Fri, 24 Jun 2022 22:08:25 +0900
> > 
> > 
> > In emacs-lisp-mode or lisp-intraction-mode, insert following text.
> >   ;;abc def【ghi】
> >   ;;【123】456 789
> > 
> > When the cursor is before 【ghi】, highlighting is not done.
> > When the cursor is after  【ghi】, 'd' is highlighted.
> > when the cursor is before 【123】, '6' is highlighted.
> > when the cursor is after  【123】, highlighting is not done.
> 
> I cannot reproduce this.

Sorry, I take this back: I do see the problem.  It's just that being
in one of the above modes is critical for reproducing it.

bug#56188: 28.1; blink-matching-paren works wrong with non-ASCII parentheses

[Eli Zaretskii]

> From: awrhygty@outlook.com
> Date: Fri, 24 Jun 2022 22:08:25 +0900
> 
> 
> In emacs-lisp-mode or lisp-intraction-mode, insert following text.
>   ;;abc def【ghi】
>   ;;【123】456 789
> 
> When the cursor is before 【ghi】, highlighting is not done.
> When the cursor is after  【ghi】, 'd' is highlighted.
> when the cursor is before 【123】, '6' is highlighted.
> when the cursor is after  【123】, highlighting is not done.

Looks like this is intentional: see the variable
multibyte-syntax-as-symbol.  It is t in these two modes.  If you set
it to nil, you get the behavior you expect.

So it looks like there's no bug here.

bug#56188: 28.1; blink-matching-paren works wrong with non-ASCII parentheses

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> When the cursor is before 【ghi】, highlighting is not done.
>> When the cursor is after  【ghi】, 'd' is highlighted.
>> when the cursor is before 【123】, '6' is highlighted.
>> when the cursor is after  【123】, highlighting is not done.
>
> Looks like this is intentional: see the variable
> multibyte-syntax-as-symbol.  It is t in these two modes.  If you set
> it to nil, you get the behavior you expect.
>
> So it looks like there's no bug here.

I didn't understand what you meant first, but the issue is that there
are no spaces here:

  def【ghi】

I.e., this is one symbol consisting of eight characters.

However, the surprising thing is that it's blinking at all here.  If 】
is symbol constituent, then no blinking should happen, I think?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no