bug#59816: 29.0.60; c++-ts-mode handles one-line comments badly

bug#59816: 29.0.60; c++-ts-mode handles one-line comments badly

[Herman, Géza]

With the following simple program, emacs reports that "int a;" is in a 
comment:

---------------------
void foo() {
    // c
    int a;
}
---------------------

Repro steps:
- install tree-sitter-cpp available at 
https://github.com/tree-sitter/tree-sitter-cpp
- copy the program above into a buffer
- switch to c++-ts-mode
- at the line "int a;", put the cursor at the 'i' (or anywhere in the 
line, exact position doesn't seem to matter)
- M-: (nth 4 (syntax-ppss (point)))

For me, this incorrectly returns "t". In c++-mode (without tree sitter), 
this correctly returns "nil".

If I replace "// c" with "/* c */", the bug doesn't happen. It seems 
that one line comments don't end at the end of the line but last until 
the end of the buffer.

The AST looks like this (with both comment styles there are the same) 
using treesit-explore-mode:

(function_definition type: (primitive_type)
  declarator:
   (function_declarator declarator: (identifier)
    parameters: (parameter_list ( )))
  body:
   (compound_statement { (comment)
    (declaration type: (primitive_type) declarator: (identifier) ;)
    }))

Note I'm not sure whether this is an emacs, tree-sitter or 
tree-sitter-cpp bug. But because the AST is the same for /* */ kind of 
comment, and also if press RET on "(comment)" then only the "// c" 
comment is highlighted (so tree-sitter reports the correct area for the 
comment), I suppose that this is an emacs-related problem.


In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version
  3.24.20, cairo version 1.16.0) of 2022-12-04 built on zetor
Repository revision: 84214578f5a2ff0d45312d9385442583f6877fb5
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid

Configured using:
  'configure --with-native-compilation --without-compress-install
  --with-xinput2 --with-xwidgets --with-tree-sitter
  'CFLAGS=-fno-omit-frame-pointer -g3 -O2''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM XINPUT2 XPM
XWIDGETS GTK3 ZLIB

Important settings:
   value of $LC_ALL: C.UTF-8
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=none
   locale-coding-system: utf-8-unix

Major mode: C++//l

Minor modes in effect:
   tooltip-mode: t
   global-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
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs c-ts-mode treesit cl-loaddefs comp comp-cstr warnings icons
subr-x rx cl-seq cl-macs gv cl-extra help-mode bytecomp byte-compile
cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd 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 nadvice seq simple cl-generic indonesian philippine
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 abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads xwidget-internal dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
xinput2 x multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 108555 6531)
  (symbols 48 9153 0)
  (strings 32 26241 1411)
  (string-bytes 1 905477)
  (vectors 16 18498)
  (vector-slots 8 368704 14814)
  (floats 8 42 316)
  (intervals 56 400 0)
  (buffers 992 11))

bug#59816: [PATCH]: bug#59816: 29.0.60; c++-ts-mode handles one-line comments badly

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

Herman, Géza <geza.herman@gmail.com> writes:

> With the following simple program, emacs reports that "int a;" is in a comment:
>
> ---------------------
> void foo() {
>    // c
>    int a;
> }
> ---------------------
>
> Repro steps:
> - install tree-sitter-cpp available at
>   https://github.com/tree-sitter/tree-sitter-cpp
> - copy the program above into a buffer
> - switch to c++-ts-mode
> - at the line "int a;", put the cursor at the 'i' (or anywhere in the line,
>  exact position doesn't seem to matter)
> - M-: (nth 4 (syntax-ppss (point)))
>
> For me, this incorrectly returns "t". In c++-mode (without tree sitter), this
> correctly returns "nil".
>


You're right.  This is my bad.  This patch addresses it.  What do you
think, Eli?  BTW - I see that many modes in general don't refer to their
syntax-tables in their define-derived-mode form.  Is that intentional?

Theo


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-syntax-table-for-tree-sitter-modes.patch --]
[-- Type: text/x-diff, Size: 5571 bytes --]

From b59c4cf3b238291fab57e6de47c60c5bdca3bc4f Mon Sep 17 00:00:00 2001
From: Theodor Thornhill <theo@thornhill.no>
Date: Mon, 5 Dec 2022 13:37:58 +0100
Subject: [PATCH] Fix syntax-table for tree-sitter modes

When adapting the 'c-populate-syntax-table' for tree-sitter, I misread
the code, and thus some crucial entries were missing.  For the
relevant modes we use the same table as specified in the
non-tree-sitter major mode.

* lisp/progmodes/c-ts-mode.el (c-ts-mode--syntax-table): Add new
entries.
* lisp/progmodes/csharp-mode.el (csharp-ts-mode): Add new entries.
* lisp/progmodes/java-ts-mode.el (java-ts-mode--syntax-table): Add new
entries.
* lisp/progmodes/json-ts-mode.el (json-ts-mode--syntax-table): Add new
entries.
* lisp/progmodes/typescript-ts-mode.el
(typescript-ts-mode--syntax-table): Add new entries.
* lisp/textmodes/css-mode.el (css-ts-mode): Add new entries.
---
 lisp/progmodes/c-ts-mode.el          | 2 ++
 lisp/progmodes/csharp-mode.el        | 1 +
 lisp/progmodes/java-ts-mode.el       | 5 +++++
 lisp/progmodes/json-ts-mode.el       | 8 +++++---
 lisp/progmodes/typescript-ts-mode.el | 9 +++++++--
 lisp/textmodes/css-mode.el           | 1 +
 6 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index 1bd093cfa2..0fcc9b9fe4 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -79,6 +79,8 @@ c-ts-mode--syntax-table
     (modify-syntax-entry ?\240 "."   table)
     (modify-syntax-entry ?/  ". 124b" table)
     (modify-syntax-entry ?*  ". 23"   table)
+    (modify-syntax-entry ?\n "> b"  table)
+    (modify-syntax-entry ?\^m "> b" table)
     table)
   "Syntax table for `c-ts-mode'.")
 
diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el
index 054dabfed0..bb721e248a 100644
--- a/lisp/progmodes/csharp-mode.el
+++ b/lisp/progmodes/csharp-mode.el
@@ -890,6 +890,7 @@ csharp-mode
 ;;;###autoload
 (define-derived-mode csharp-ts-mode prog-mode "C#"
   "Major mode for editing C# code."
+  :syntax-table (csharp--make-mode-syntax-table)
 
   (unless (treesit-ready-p 'c-sharp)
     (error "Tree-sitter for C# isn't available"))
diff --git a/lisp/progmodes/java-ts-mode.el b/lisp/progmodes/java-ts-mode.el
index 2c42505ac9..f947efc5a4 100644
--- a/lisp/progmodes/java-ts-mode.el
+++ b/lisp/progmodes/java-ts-mode.el
@@ -58,6 +58,11 @@ java-ts-mode--syntax-table
     (modify-syntax-entry ?|  "."     table)
     (modify-syntax-entry ?\' "\""    table)
     (modify-syntax-entry ?\240 "."   table)
+    (modify-syntax-entry ?/  ". 124b" table)
+    (modify-syntax-entry ?*  ". 23"   table)
+    (modify-syntax-entry ?\n "> b"  table)
+    (modify-syntax-entry ?\^m "> b" table)
+    (modify-syntax-entry ?@ "'" table)
     table)
   "Syntax table for `java-ts-mode'.")
 
diff --git a/lisp/progmodes/json-ts-mode.el b/lisp/progmodes/json-ts-mode.el
index 101e873cf6..cd96b139be 100644
--- a/lisp/progmodes/json-ts-mode.el
+++ b/lisp/progmodes/json-ts-mode.el
@@ -46,9 +46,7 @@ json-ts-mode-indent-offset
 
 (defvar json-ts-mode--syntax-table
   (let ((table (make-syntax-table)))
-    ;; Taken from the cc-langs version
     (modify-syntax-entry ?_  "_"     table)
-    (modify-syntax-entry ?$ "_"      table)
     (modify-syntax-entry ?\\ "\\"    table)
     (modify-syntax-entry ?+  "."     table)
     (modify-syntax-entry ?-  "."     table)
@@ -58,8 +56,12 @@ json-ts-mode--syntax-table
     (modify-syntax-entry ?>  "."     table)
     (modify-syntax-entry ?&  "."     table)
     (modify-syntax-entry ?|  "."     table)
-    (modify-syntax-entry ?` "\""     table)
+    (modify-syntax-entry ?\' "\""    table)
     (modify-syntax-entry ?\240 "."   table)
+    (modify-syntax-entry ?/  ". 124b" table)
+    (modify-syntax-entry ?*  ". 23"   table)
+    (modify-syntax-entry ?\n "> b"  table)
+    (modify-syntax-entry ?\^m "> b" table)
     table)
   "Syntax table for `json-ts-mode'.")
 
diff --git a/lisp/progmodes/typescript-ts-mode.el b/lisp/progmodes/typescript-ts-mode.el
index 48ac1169fe..c7edbb40f8 100644
--- a/lisp/progmodes/typescript-ts-mode.el
+++ b/lisp/progmodes/typescript-ts-mode.el
@@ -45,7 +45,6 @@ typescript-ts-mode--syntax-table
   (let ((table (make-syntax-table)))
     ;; Taken from the cc-langs version
     (modify-syntax-entry ?_  "_"     table)
-    (modify-syntax-entry ?$ "_"      table)
     (modify-syntax-entry ?\\ "\\"    table)
     (modify-syntax-entry ?+  "."     table)
     (modify-syntax-entry ?-  "."     table)
@@ -55,8 +54,14 @@ typescript-ts-mode--syntax-table
     (modify-syntax-entry ?>  "."     table)
     (modify-syntax-entry ?&  "."     table)
     (modify-syntax-entry ?|  "."     table)
-    (modify-syntax-entry ?` "\""     table)
+    (modify-syntax-entry ?\' "\""    table)
     (modify-syntax-entry ?\240 "."   table)
+    (modify-syntax-entry ?/  ". 124b" table)
+    (modify-syntax-entry ?*  ". 23"   table)
+    (modify-syntax-entry ?\n "> b"  table)
+    (modify-syntax-entry ?\^m "> b" table)
+    (modify-syntax-entry ?$ "_" table)
+    (modify-syntax-entry ?` "\"" table)
     table)
   "Syntax table for `typescript-ts-mode'.")
 
diff --git a/lisp/textmodes/css-mode.el b/lisp/textmodes/css-mode.el
index b82886e397..b3654eaa7f 100644
--- a/lisp/textmodes/css-mode.el
+++ b/lisp/textmodes/css-mode.el
@@ -1822,6 +1822,7 @@ css-ts-mode
 can also be used to fill comments.
 
 \\{css-mode-map}"
+  :syntax-table css-mode-syntax-table
   (when (treesit-ready-p 'css)
     ;; Borrowed from `css-mode'.
     (add-hook 'completion-at-point-functions
-- 
2.34.1

bug#59816: [PATCH]: bug#59816: 29.0.60; c++-ts-mode handles one-line comments badly

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: geza.herman@gmail.com, eliz@gnu.org
> Date: Mon, 05 Dec 2022 13:44:49 +0100
> 
> You're right.  This is my bad.  This patch addresses it.  What do you
> think, Eli?

I'll defer to people who know more than I do about these modes.

> BTW - I see that many modes in general don't refer to their
> syntax-tables in their define-derived-mode form.  Is that intentional?

The ELisp manual says:

 -- Macro: define-derived-mode variant parent name docstring
          keyword-args... body...
     This macro defines VARIANT as a major mode command, using NAME as
     the string form of the mode name.  VARIANT and PARENT should be
     unquoted symbols.

     The new command VARIANT is defined to call the function PARENT,
     then override certain aspects of that parent mode:

        [...]

        • The new mode has its own syntax table, kept in the variable
          ‘VARIANT-syntax-table’, unless you override this using the
          ‘:syntax-table’ keyword (see below).  ‘define-derived-mode’
          makes the parent mode’s syntax-table the parent of
          ‘VARIANT-syntax-table’, unless the latter is already set and
          already has a parent different from the standard syntax table.

So there's no need to mention it because it happens automatically.

bug#59816: [PATCH]: bug#59816: 29.0.60; c++-ts-mode handles one-line comments badly

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: geza.herman@gmail.com, eliz@gnu.org
>> Date: Mon, 05 Dec 2022 13:44:49 +0100
>> 
>> You're right.  This is my bad.  This patch addresses it.  What do you
>> think, Eli?
>
> I'll defer to people who know more than I do about these modes.
>

Sure, added Yuan to CC.

>> BTW - I see that many modes in general don't refer to their
>> syntax-tables in their define-derived-mode form.  Is that intentional?
>
> The ELisp manual says:
>
>  -- Macro: define-derived-mode variant parent name docstring
>           keyword-args... body...
>      This macro defines VARIANT as a major mode command, using NAME as
>      the string form of the mode name.  VARIANT and PARENT should be
>      unquoted symbols.
>
>      The new command VARIANT is defined to call the function PARENT,
>      then override certain aspects of that parent mode:
>
>         [...]
>
>         • The new mode has its own syntax table, kept in the variable
>           ‘VARIANT-syntax-table’, unless you override this using the
>           ‘:syntax-table’ keyword (see below).  ‘define-derived-mode’
>           makes the parent mode’s syntax-table the parent of
>           ‘VARIANT-syntax-table’, unless the latter is already set and
>           already has a parent different from the standard syntax table.
>
> So there's no need to mention it because it happens automatically.

Right, thanks!

Can you test this patch, Herman, and see if it works for you now?

Theo

bug#59816: 29.0.60; c++-ts-mode handles one-line comments badly

[Alan Mackenzie]

Hello, Theodor,

Perhaps a little different from the original bug report, but while you're
at it, you may want to handle continued C++ line comments (I haven't
checked whether you've done this already, so apologies if so).

Here, in a comment, if the last character on the comment line is a \,
this continues the comment onto the next line.  This backslash cannot
itself be escaped, so a comment line ending in \\ continues on to the
next line, too.

All the best with it!

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#59816: 29.0.60; c++-ts-mode handles one-line comments badly

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 5 December 2022 17:44:14 CET, Alan Mackenzie <acm@muc.de> wrote:
>Hello, Theodor,
>
>Perhaps a little different from the original bug report, but while you're
>at it, you may want to handle continued C++ line comments (I haven't
>checked whether you've done this already, so apologies if so).
>
>Here, in a comment, if the last character on the comment line is a \,
>this continues the comment onto the next line.  This backslash cannot
>itself be escaped, so a comment line ending in \\ continues on to the
>next line, too.
>

Do you mean fontlock-wise or syntax-wise? Maybe both?


>All the best with it!
>

Thanks, and thanks for the tip!

Theo :)

bug#59816: [PATCH]: bug#59816: 29.0.60; c++-ts-mode handles one-line comments badly

[Herman, Géza]

Hi Theo, yes, it works correctly with your patch, thanks!

On 12/5/22 14:21, Theodor Thornhill wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Theodor Thornhill <theo@thornhill.no>
>>> Cc: geza.herman@gmail.com, eliz@gnu.org
>>> Date: Mon, 05 Dec 2022 13:44:49 +0100
>>>
>>> You're right.  This is my bad.  This patch addresses it.  What do you
>>> think, Eli?
>> I'll defer to people who know more than I do about these modes.
>>
> Sure, added Yuan to CC.
>
>>> BTW - I see that many modes in general don't refer to their
>>> syntax-tables in their define-derived-mode form.  Is that intentional?
>> The ELisp manual says:
>>
>>   -- Macro: define-derived-mode variant parent name docstring
>>            keyword-args... body...
>>       This macro defines VARIANT as a major mode command, using NAME as
>>       the string form of the mode name.  VARIANT and PARENT should be
>>       unquoted symbols.
>>
>>       The new command VARIANT is defined to call the function PARENT,
>>       then override certain aspects of that parent mode:
>>
>>          [...]
>>
>>          • The new mode has its own syntax table, kept in the variable
>>            ‘VARIANT-syntax-table’, unless you override this using the
>>            ‘:syntax-table’ keyword (see below).  ‘define-derived-mode’
>>            makes the parent mode’s syntax-table the parent of
>>            ‘VARIANT-syntax-table’, unless the latter is already set and
>>            already has a parent different from the standard syntax table.
>>
>> So there's no need to mention it because it happens automatically.
> Right, thanks!
>
> Can you test this patch, Herman, and see if it works for you now?
>
> Theo

bug#59816: [PATCH]: bug#59816: 29.0.60; c++-ts-mode handles one-line comments badly

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 6 December 2022 00:16:53 CET, "Herman, Géza" <geza.herman@gmail.com> wrote:
>Hi Theo, yes, it works correctly with your patch, thanks!
>
>On 12/5/22 14:21, Theodor Thornhill wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>>> From: Theodor Thornhill <theo@thornhill.no>
>>>> Cc: geza.herman@gmail.com, eliz@gnu.org
>>>> Date: Mon, 05 Dec 2022 13:44:49 +0100
>>>> 
>>>> You're right.  This is my bad.  This patch addresses it.  What do you
>>>> think, Eli?
>>> I'll defer to people who know more than I do about these modes.
>>> 
>> Sure, added Yuan to CC.
>> 
>>>> BTW - I see that many modes in general don't refer to their
>>>> syntax-tables in their define-derived-mode form.  Is that intentional?
>>> The ELisp manual says:
>>> 
>>>   -- Macro: define-derived-mode variant parent name docstring
>>>            keyword-args... body...
>>>       This macro defines VARIANT as a major mode command, using NAME as
>>>       the string form of the mode name.  VARIANT and PARENT should be
>>>       unquoted symbols.
>>> 
>>>       The new command VARIANT is defined to call the function PARENT,
>>>       then override certain aspects of that parent mode:
>>> 
>>>          [...]
>>> 
>>>          • The new mode has its own syntax table, kept in the variable
>>>            ‘VARIANT-syntax-table’, unless you override this using the
>>>            ‘:syntax-table’ keyword (see below).  ‘define-derived-mode’
>>>            makes the parent mode’s syntax-table the parent of
>>>            ‘VARIANT-syntax-table’, unless the latter is already set and
>>>            already has a parent different from the standard syntax table.
>>> 
>>> So there's no need to mention it because it happens automatically.
>> Right, thanks!
>> 
>> Can you test this patch, Herman, and see if it works for you now?
>> 
>> Theo
>

Nice, thanks for testing!
Yuan, will you apply this patch?
Theo

bug#59816: 29.0.60; c++-ts-mode handles one-line comments badly

[Yuan Fu]

Theodor Thornhill <theo@thornhill.no> writes:

> On 6 December 2022 00:16:53 CET, "Herman, Géza" <geza.herman@gmail.com> wrote:
>>Hi Theo, yes, it works correctly with your patch, thanks!
>>
>>On 12/5/22 14:21, Theodor Thornhill wrote:
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>>>> From: Theodor Thornhill <theo@thornhill.no>
>>>>> Cc: geza.herman@gmail.com, eliz@gnu.org
>>>>> Date: Mon, 05 Dec 2022 13:44:49 +0100
>>>>> 
>>>>> You're right.  This is my bad.  This patch addresses it.  What do you
>>>>> think, Eli?
>>>> I'll defer to people who know more than I do about these modes.
>>>> 
>>> Sure, added Yuan to CC.
>>> 
>>>>> BTW - I see that many modes in general don't refer to their
>>>>> syntax-tables in their define-derived-mode form.  Is that intentional?
>>>> The ELisp manual says:
>>>> 
>>>>   -- Macro: define-derived-mode variant parent name docstring
>>>>            keyword-args... body...
>>>>       This macro defines VARIANT as a major mode command, using NAME as
>>>>       the string form of the mode name.  VARIANT and PARENT should be
>>>>       unquoted symbols.
>>>> 
>>>>       The new command VARIANT is defined to call the function PARENT,
>>>>       then override certain aspects of that parent mode:
>>>> 
>>>>          [...]
>>>> 
>>>>          • The new mode has its own syntax table, kept in the variable
>>>>            ‘VARIANT-syntax-table’, unless you override this using the
>>>>            ‘:syntax-table’ keyword (see below).  ‘define-derived-mode’
>>>>            makes the parent mode’s syntax-table the parent of
>>>>            ‘VARIANT-syntax-table’, unless the latter is already set and
>>>>            already has a parent different from the standard syntax table.
>>>> 
>>>> So there's no need to mention it because it happens automatically.
>>> Right, thanks!
>>> 
>>> Can you test this patch, Herman, and see if it works for you now?
>>> 
>>> Theo
>>
>
> Nice, thanks for testing!
> Yuan, will you apply this patch?
> Theo

Applied the patch, Thanks!

Yuan