unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
@ 2022-11-23  2:24 Eason Huang
  2022-11-23  8:44 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 15+ messages in thread
From: Eason Huang @ 2022-11-23  2:24 UTC (permalink / raw)
  To: 59498


Hi emacs-devel,

I just tried the c++-ts-mode, but it didn't worked.

steps to reproduce:

1. luanch Emacs with emacs -Q
2. C-x, C-f ~/test.cpp
3. M-x, toggle-debug-on-error
4. M-x, c++-ts-mode, now you will get the errors as bellow:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  treesit-ready-p(cpp)
  c++-ts-mode()
  funcall-interactively(c++-ts-mode)
  command-execute(c++-ts-mode record)
  execute-extended-command(nil "c++-ts-mode" "c++-ts")
  funcall-interactively(execute-extended-command nil "c++-ts-mode" "c++-ts")
  command-execute(execute-extended-command)

By the way, python-ts-mode works well.

I builded Emacs 29.0.50 with this commit:
https://github.com/emacs-mirror/emacs/commit/057901f55ad12ebbc9cf092dd6ad0f02539849f9

----
Eason Huang


In GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin22.1.0, NS
 appkit-2299.00 Version 13.0.1 (Build 22A400)) of 2022-11-23 built on
 macbook
Windowing system distributor 'Apple', version 10.3.2299
System Description:  macOS 13.0.1

Configured using:
 'configure --with-native-compilation=aot 'CPPFLAGS=-I/opt/local/include
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk'
 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-rpath
 /opt/local/lib/gcc12
 -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
 -arch x86_64''

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Text

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

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 help-fns
radix-tree cl-print byte-opt debug backtrace find-func c-ts-mode treesit
cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs cl-loaddefs comp comp-cstr warnings icons subr-x rx
cl-seq cl-macs gv cl-extra help-mode bytecomp byte-compile cl-lib
cus-start cus-load rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/ns-win ns-win ucs-normalize mule-util 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 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 kqueue cocoa ns lcms2
multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 124747 11782)
 (symbols 48 10326 0)
 (strings 32 29161 1312)
 (string-bytes 1 989243)
 (vectors 16 19575)
 (vector-slots 8 393723 16844)
 (floats 8 35 39)
 (intervals 56 419 0)
 (buffers 992 15))





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-23  2:24 bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled Eason Huang
@ 2022-11-23  8:44 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-11-23 10:53   ` Eason Huang
  0 siblings, 1 reply; 15+ messages in thread
From: Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-11-23  8:44 UTC (permalink / raw)
  To: Eason Huang; +Cc: 59498

Eason Huang <aqua0210@foxmail.com> writes:

> Hi emacs-devel,
>
> I just tried the c++-ts-mode, but it didn't worked.
>
> steps to reproduce:
>
> 1. luanch Emacs with emacs -Q
> 2. C-x, C-f ~/test.cpp
> 3. M-x, toggle-debug-on-error
> 4. M-x, c++-ts-mode, now you will get the errors as bellow:
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   treesit-ready-p(cpp)
>   c++-ts-mode()
>   funcall-interactively(c++-ts-mode)
>   command-execute(c++-ts-mode record)
>   execute-extended-command(nil "c++-ts-mode" "c++-ts")
>   funcall-interactively(execute-extended-command nil "c++-ts-mode" "c++-ts")
>   command-execute(execute-extended-command)
>
> By the way, python-ts-mode works well.
>
> I builded Emacs 29.0.50 with this commit:
> https://github.com/emacs-mirror/emacs/commit/057901f55ad12ebbc9cf092dd6ad0f02539849f9

Could you try an Emacs build that contains commit c69858b3f0?  This is
the same bug as bug#59497.  Thanks.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-23  8:44 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-11-23 10:53   ` Eason Huang
  2022-11-24 14:39     ` Randy Taylor
  0 siblings, 1 reply; 15+ messages in thread
From: Eason Huang @ 2022-11-23 10:53 UTC (permalink / raw)
  To: Daniel Martín; +Cc: 59498

Daniel Martín <mardani29@yahoo.es> writes:

> Eason Huang <aqua0210@foxmail.com> writes:
>
>> Hi emacs-devel,
>>
>> I just tried the c++-ts-mode, but it didn't worked.
>>
>> steps to reproduce:
>>
>> 1. luanch Emacs with emacs -Q
>> 2. C-x, C-f ~/test.cpp
>> 3. M-x, toggle-debug-on-error
>> 4. M-x, c++-ts-mode, now you will get the errors as bellow:
>>
>> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>>   treesit-ready-p(cpp)
>>   c++-ts-mode()
>>   funcall-interactively(c++-ts-mode)
>>   command-execute(c++-ts-mode record)
>>   execute-extended-command(nil "c++-ts-mode" "c++-ts")
>>   funcall-interactively(execute-extended-command nil "c++-ts-mode" "c++-ts")
>>   command-execute(execute-extended-command)
>>
>> By the way, python-ts-mode works well.
>>
>> I builded Emacs 29.0.50 with this commit:
>> https://github.com/emacs-mirror/emacs/commit/057901f55ad12ebbc9cf092dd6ad0f02539849f9
>
> Could you try an Emacs build that contains commit c69858b3f0?  This is
> the same bug as bug#59497.  Thanks.

Hi Daniel,

I build the latest commit(9f4306cd) and try it a again. This issue have
been fixed.

But when I try to indent code,
it will raise the error (Wrong type argument: stringp, nil) again.
It should be a different bug.

Steps to reproduce:

After the step 4, try to type the code as below:

int main(){
<-- put you cursor at the first colum 1, and then hit TAB(indent-for-tab-command)

}

after you hit TAB at the above code, you will get the backtrace error as
below:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  looking-at(nil t)
  #f(compiled-function (&rest _) #<bytecode 0x18b0dfc57c56ebd8>)(nil #<treesit-node (compound_statement) in 11-15> 13)
  #f(compiled-function (fn) #<bytecode 0x188c898311f019af>)(#f(compiled-function (&rest _) #<bytecode 0x18b0dfc57c56ebd8>))
  mapcar(#f(compiled-function (fn) #<bytecode 0x188c898311f019af>) (#f(compiled-function (n parent &rest _) #<bytecode 0x149caa867664fee9>) #f(compiled-function (&rest _) #<bytecode 0x18b0dfc57c56ebd8>)))
  #f(compiled-function (node parent bol &rest _) #<bytecode -0xb869f433d8fc770>)(nil #<treesit-node (compound_statement) in 11-15> 13)
  treesit--simple-indent-eval(((and (parent-is "comment") comment-end) nil #<treesit-node (compound_statement) in 11-15> 13))
  treesit-simple-indent(nil #<treesit-node (compound_statement) in 11-15> 13)
  treesit--indent-1()
  treesit-indent()
  indent-according-to-mode()
  electric-indent-post-self-insert-function()
  newline(nil 1)
  funcall-interactively(newline nil 1)
  command-execute(newline)


-- 
Eason Huang





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-23 10:53   ` Eason Huang
@ 2022-11-24 14:39     ` Randy Taylor
  2022-11-25 12:56       ` Eason Huang
  2022-11-26 11:18       ` Eli Zaretskii
  0 siblings, 2 replies; 15+ messages in thread
From: Randy Taylor @ 2022-11-24 14:39 UTC (permalink / raw)
  To: Eason Huang; +Cc: Yuan Fu, 59498, Daniel Martín

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

On Wednesday, November 23rd, 2022 at 05:53, Eason Huang <aqua0210@foxmail.com> wrote:

> 
> 
> But when I try to indent code,
> it will raise the error (Wrong type argument: stringp, nil) again.
> It should be a different bug.
> 
> Steps to reproduce:
> 
> After the step 4, try to type the code as below:
> 
> int main(){
> <-- put you cursor at the first colum 1, and then hit TAB(indent-for-tab-command)
> 
> }
> 
> after you hit TAB at the above code, you will get the backtrace error as
> below:
> 
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
> looking-at(nil t)
> #f(compiled-function (&rest _) #<bytecode 0x18b0dfc57c56ebd8>)(nil #<treesit-node (compound_statement) in 11-15> 13)
> 
> #f(compiled-function (fn) #<bytecode 0x188c898311f019af>)(#f(compiled-function (&rest _) #<bytecode 0x18b0dfc57c56ebd8>))
> 
> mapcar(#f(compiled-function (fn) #<bytecode 0x188c898311f019af>) (#f(compiled-function (n parent &rest _) #<bytecode 0x149caa867664fee9>) #f(compiled-function (&rest _) #<bytecode 0x18b0dfc57c56ebd8>)))
> 
> #f(compiled-function (node parent bol &rest _) #<bytecode -0xb869f433d8fc770>)(nil #<treesit-node (compound_statement) in 11-15> 13)
> 
> treesit--simple-indent-eval(((and (parent-is "comment") comment-end) nil #<treesit-node (compound_statement) in 11-15> 13))
> 
> treesit-simple-indent(nil #<treesit-node (compound_statement) in 11-15> 13)
> 
> treesit--indent-1()
> treesit-indent()
> indent-according-to-mode()
> electric-indent-post-self-insert-function()
> newline(nil 1)
> funcall-interactively(newline nil 1)
> command-execute(newline)
> 
> 
> --
> Eason Huang
> 

The attached patch fixes it for me.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-c-ts-mode-indentation-Bug-59498.patch --]
[-- Type: text/x-patch; name=0001-Fix-c-ts-mode-indentation-Bug-59498.patch, Size: 882 bytes --]

From 94d7bd76b8ec48378b044ff691fb5ef2f9698c08 Mon Sep 17 00:00:00 2001
From: Randy Taylor <dev@rjt.dev>
Date: Thu, 24 Nov 2022 09:31:53 -0500
Subject: [PATCH] Fix c++-ts-mode indentation (Bug#59498)

* lisp/progmodes/c-ts-mode.el (c++-ts-mode): Set treesit-comment-start
and treesit-comment-end.
---
 lisp/progmodes/c-ts-mode.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index fc35d9aedda..48f504214e2 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -570,6 +570,8 @@ c++-ts-mode
   (setq-local comment-start "// ")
   (setq-local comment-start-skip "\\(?://+\\|/\\*+\\)\\s *")
   (setq-local comment-end "")
+  (setq-local treesit-comment-start (rx "/" (or (+ "/") (+ "*"))))
+  (setq-local treesit-comment-end (rx (+ (or "*")) "/"))
 
   (treesit-parser-create 'cpp)
 
-- 
2.38.1


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-24 14:39     ` Randy Taylor
@ 2022-11-25 12:56       ` Eason Huang
  2022-11-26 11:18       ` Eli Zaretskii
  1 sibling, 0 replies; 15+ messages in thread
From: Eason Huang @ 2022-11-25 12:56 UTC (permalink / raw)
  To: Randy Taylor; +Cc: Yuan Fu, 59498, Daniel Martín

Randy Taylor <dev@rjt.dev> writes:

> On Wednesday, November 23rd, 2022 at 05:53, Eason Huang <aqua0210@foxmail.com> wrote:
>
>>
>>
>> But when I try to indent code,
>> it will raise the error (Wrong type argument: stringp, nil) again.
>> It should be a different bug.
>>
>> Steps to reproduce:
>>
>> After the step 4, try to type the code as below:
>>
>> int main(){
>> <-- put you cursor at the first colum 1, and then hit TAB(indent-for-tab-command)
>>
>> }
>>
>> after you hit TAB at the above code, you will get the backtrace error as
>> below:
>>
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>> looking-at(nil t)
>> #f(compiled-function (&rest _) #<bytecode 0x18b0dfc57c56ebd8>)(nil #<treesit-node (compound_statement) in 11-15> 13)
>>
>> #f(compiled-function (fn) #<bytecode 0x188c898311f019af>)(#f(compiled-function (&rest _) #<bytecode 0x18b0dfc57c56ebd8>))
>>
>> mapcar(#f(compiled-function (fn) #<bytecode 0x188c898311f019af>)
>> (#f(compiled-function (n parent &rest _) #<bytecode
>> 0x149caa867664fee9>) #f(compiled-function (&rest _) #<bytecode
>> 0x18b0dfc57c56ebd8>)))
>>
>> #f(compiled-function (node parent bol &rest _) #<bytecode -0xb869f433d8fc770>)(nil #<treesit-node (compound_statement) in 11-15> 13)
>>
>> treesit--simple-indent-eval(((and (parent-is "comment") comment-end) nil #<treesit-node (compound_statement) in 11-15> 13))
>>
>> treesit-simple-indent(nil #<treesit-node (compound_statement) in 11-15> 13)
>>
>> treesit--indent-1()
>> treesit-indent()
>> indent-according-to-mode()
>> electric-indent-post-self-insert-function()
>> newline(nil 1)
>> funcall-interactively(newline nil 1)
>> command-execute(newline)
>>
>>
>> --
>> Eason Huang
>>
>
> The attached patch fixes it for me.
>
>

Hi Randy,

Thanks for your patch, I tested on macOS 13.0.1. And I can confirm that it
fixes the issue of indentation.

Hope it can be merged to master.


-- 
Eason Huang





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-24 14:39     ` Randy Taylor
  2022-11-25 12:56       ` Eason Huang
@ 2022-11-26 11:18       ` Eli Zaretskii
  2022-11-26 22:11         ` Yuan Fu
  1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2022-11-26 11:18 UTC (permalink / raw)
  To: Randy Taylor, Yuan Fu; +Cc: aqua0210, 59498, mardani29

> Cc: Yuan Fu <casouri@gmail.com>, 59498@debbugs.gnu.org,
>  Daniel Martín <mardani29@yahoo.es>
> Date: Thu, 24 Nov 2022 14:39:19 +0000
> From: Randy Taylor <dev@rjt.dev>
> 
> diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
> index fc35d9aedda..48f504214e2 100644
> --- a/lisp/progmodes/c-ts-mode.el
> +++ b/lisp/progmodes/c-ts-mode.el
> @@ -570,6 +570,8 @@ c++-ts-mode
>    (setq-local comment-start "// ")
>    (setq-local comment-start-skip "\\(?://+\\|/\\*+\\)\\s *")
>    (setq-local comment-end "")
> +  (setq-local treesit-comment-start (rx "/" (or (+ "/") (+ "*"))))
> +  (setq-local treesit-comment-end (rx (+ (or "*")) "/"))
>  
>    (treesit-parser-create 'cpp)

Thanks, but this doesn't look right to me: why should c++-ts-mode set
variables for treesit.el?  It is more likely that treesit.el should use the
buffer-local values of comment-start and comment-end instead, and fall back
on generic values (if they make sense) only if the local values are not set.

Yuan, WDYT?





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-26 11:18       ` Eli Zaretskii
@ 2022-11-26 22:11         ` Yuan Fu
  2022-11-27  6:24           ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Yuan Fu @ 2022-11-26 22:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Randy Taylor, aqua0210, 59498, mardani29



> On Nov 26, 2022, at 3:18 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Cc: Yuan Fu <casouri@gmail.com>, 59498@debbugs.gnu.org,
>> Daniel Martín <mardani29@yahoo.es>
>> Date: Thu, 24 Nov 2022 14:39:19 +0000
>> From: Randy Taylor <dev@rjt.dev>
>> 
>> diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
>> index fc35d9aedda..48f504214e2 100644
>> --- a/lisp/progmodes/c-ts-mode.el
>> +++ b/lisp/progmodes/c-ts-mode.el
>> @@ -570,6 +570,8 @@ c++-ts-mode
>>   (setq-local comment-start "// ")
>>   (setq-local comment-start-skip "\\(?://+\\|/\\*+\\)\\s *")
>>   (setq-local comment-end "")
>> +  (setq-local treesit-comment-start (rx "/" (or (+ "/") (+ "*"))))
>> +  (setq-local treesit-comment-end (rx (+ (or "*")) "/"))
>> 
>>   (treesit-parser-create 'cpp)
> 
> Thanks, but this doesn't look right to me: why should c++-ts-mode set
> variables for treesit.el?  It is more likely that treesit.el should use the
> buffer-local values of comment-start and comment-end instead, and fall back
> on generic values (if they make sense) only if the local values are not set.
> 
> Yuan, WDYT?

I added treesit-comment-start/end to help indenting comments. So this is the correct way to use them. The following comment explains why I created new variables:

;; `comment-start' and `comment-end' assume there is only one type of
;; comment, and that the comment spans only one line.  So they are not
;; sufficient for our purpose.

Yuan




^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-26 22:11         ` Yuan Fu
@ 2022-11-27  6:24           ` Eli Zaretskii
  2022-11-27  7:18             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2022-11-27  6:24 UTC (permalink / raw)
  To: Yuan Fu, Stefan Monnier; +Cc: dev, aqua0210, 59498, mardani29

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 26 Nov 2022 14:11:48 -0800
> Cc: Randy Taylor <dev@rjt.dev>,
>  aqua0210@foxmail.com,
>  59498@debbugs.gnu.org,
>  mardani29@yahoo.es
> 
> >> +  (setq-local treesit-comment-start (rx "/" (or (+ "/") (+ "*"))))
> >> +  (setq-local treesit-comment-end (rx (+ (or "*")) "/"))
> >> 
> >>   (treesit-parser-create 'cpp)
> > 
> > Thanks, but this doesn't look right to me: why should c++-ts-mode set
> > variables for treesit.el?  It is more likely that treesit.el should use the
> > buffer-local values of comment-start and comment-end instead, and fall back
> > on generic values (if they make sense) only if the local values are not set.
> > 
> > Yuan, WDYT?
> 
> I added treesit-comment-start/end to help indenting comments. So this is the correct way to use them. The following comment explains why I created new variables:
> 
> ;; `comment-start' and `comment-end' assume there is only one type of
> ;; comment, and that the comment spans only one line.  So they are not
> ;; sufficient for our purpose.

??? This is surprisingly unclean, IMO.  For starters, the names of the
variables are confusing.  The need to define two sets of comment-start and
comment-end regexps is also a nuisance and a source of errors.

How do non-treesit modes handle this issue?  Why do the treesit-based modes
need something special here?

Stefan, any ideas?





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-27  6:24           ` Eli Zaretskii
@ 2022-11-27  7:18             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-11-27  7:24               ` Eli Zaretskii
  2022-11-27 22:00               ` Yuan Fu
  0 siblings, 2 replies; 15+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-11-27  7:18 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: dev, Yuan Fu, aqua0210, 59498, mardani29

>> I added treesit-comment-start/end to help indenting comments. So this is
>> the correct way to use them. The following comment explains why I created
>> new variables:
>> 
>> ;; `comment-start' and `comment-end' assume there is only one type of
>> ;; comment, and that the comment spans only one line.  So they are not
>> ;; sufficient for our purpose.
>
> ??? This is surprisingly unclean, IMO.  For starters, the names of the
> variables are confusing.  The need to define two sets of comment-start and
> comment-end regexps is also a nuisance and a source of errors.
>
> How do non-treesit modes handle this issue?  Why do the treesit-based modes
> need something special here?
>
> Stefan, any ideas?

`comment-start` and `comment-end` do not describe the set of possible
comment delimiters.  They describe the comment delimiters that should be
*inserted* when we do things like `comment-dwim`.

To find/match comment delimiters we have `comment-start-skip` and
`comment-end-skip`.  They're not ideal, but they've been good enough so far.
They don't say which comment starter matches which comment-ender (that
was done by the syntax-tables), but tree-sitter should be able to tell
us that when we need it.

It would be nice if we could avoid the need to set/use
`comment-start-skip` and `comment-end-skip` when using tree-sitter.
Maybe we can compute their values from the tree-sitter grammar.
But getting rid of uses of those vars will take a fair bit more work,
I think.


        Stefan






^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-27  7:18             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-11-27  7:24               ` Eli Zaretskii
  2022-11-27 22:21                 ` Yuan Fu
  2022-11-27 22:00               ` Yuan Fu
  1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2022-11-27  7:24 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: dev, casouri, aqua0210, 59498, mardani29

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Yuan Fu <casouri@gmail.com>,  dev@rjt.dev,  aqua0210@foxmail.com,
>   59498@debbugs.gnu.org,  mardani29@yahoo.es
> Date: Sun, 27 Nov 2022 02:18:06 -0500
> 
> >> I added treesit-comment-start/end to help indenting comments. So this is
> >> the correct way to use them. The following comment explains why I created
> >> new variables:
> >> 
> >> ;; `comment-start' and `comment-end' assume there is only one type of
> >> ;; comment, and that the comment spans only one line.  So they are not
> >> ;; sufficient for our purpose.
> >
> > ??? This is surprisingly unclean, IMO.  For starters, the names of the
> > variables are confusing.  The need to define two sets of comment-start and
> > comment-end regexps is also a nuisance and a source of errors.
> >
> > How do non-treesit modes handle this issue?  Why do the treesit-based modes
> > need something special here?
> >
> > Stefan, any ideas?
> 
> `comment-start` and `comment-end` do not describe the set of possible
> comment delimiters.  They describe the comment delimiters that should be
> *inserted* when we do things like `comment-dwim`.
> 
> To find/match comment delimiters we have `comment-start-skip` and
> `comment-end-skip`.  They're not ideal, but they've been good enough so far.
> They don't say which comment starter matches which comment-ender (that
> was done by the syntax-tables), but tree-sitter should be able to tell
> us that when we need it.
> 
> It would be nice if we could avoid the need to set/use
> `comment-start-skip` and `comment-end-skip` when using tree-sitter.
> Maybe we can compute their values from the tree-sitter grammar.
> But getting rid of uses of those vars will take a fair bit more work,
> I think.

OK, but do you agree that adding yet another pair of variables,
treesit-comment-start/end, is the opposite of what we want?





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-27  7:18             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-11-27  7:24               ` Eli Zaretskii
@ 2022-11-27 22:00               ` Yuan Fu
  1 sibling, 0 replies; 15+ messages in thread
From: Yuan Fu @ 2022-11-27 22:00 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Randy Taylor, Eli Zaretskii, aqua0210, 59498, mardani29



> On Nov 26, 2022, at 11:18 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>> I added treesit-comment-start/end to help indenting comments. So this is
>>> the correct way to use them. The following comment explains why I created
>>> new variables:
>>> 
>>> ;; `comment-start' and `comment-end' assume there is only one type of
>>> ;; comment, and that the comment spans only one line.  So they are not
>>> ;; sufficient for our purpose.
>> 
>> ??? This is surprisingly unclean, IMO.  For starters, the names of the
>> variables are confusing.  The need to define two sets of comment-start and
>> comment-end regexps is also a nuisance and a source of errors.
>> 
>> How do non-treesit modes handle this issue?  Why do the treesit-based modes
>> need something special here?
>> 
>> Stefan, any ideas?
> 
> `comment-start` and `comment-end` do not describe the set of possible
> comment delimiters.  They describe the comment delimiters that should be
> *inserted* when we do things like `comment-dwim`.
> 
> To find/match comment delimiters we have `comment-start-skip` and
> `comment-end-skip`.  They're not ideal, but they've been good enough so far.
> They don't say which comment starter matches which comment-ender (that
> was done by the syntax-tables), but tree-sitter should be able to tell
> us that when we need it.

Ah, I should’ve done more research, sorry. comment-start/end-skip can completely replace treesit-comment-start/end.

> It would be nice if we could avoid the need to set/use
> `comment-start-skip` and `comment-end-skip` when using tree-sitter.
> Maybe we can compute their values from the tree-sitter grammar.
> But getting rid of uses of those vars will take a fair bit more work,
> I think.

Tree-sitter puts the whole comment in a single “comment” node, so there is no hope getting comment-start/end from it, sadly.

Yuan




^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-27  7:24               ` Eli Zaretskii
@ 2022-11-27 22:21                 ` Yuan Fu
  2022-11-28  0:24                   ` Stefan Kangas
  2022-11-28 13:59                   ` Eason Huang
  0 siblings, 2 replies; 15+ messages in thread
From: Yuan Fu @ 2022-11-27 22:21 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: dev, aqua0210, Stefan Monnier, 59498, mardani29



> On Nov 26, 2022, at 11:24 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Yuan Fu <casouri@gmail.com>,  dev@rjt.dev,  aqua0210@foxmail.com,
>>  59498@debbugs.gnu.org,  mardani29@yahoo.es
>> Date: Sun, 27 Nov 2022 02:18:06 -0500
>> 
>>>> I added treesit-comment-start/end to help indenting comments. So this is
>>>> the correct way to use them. The following comment explains why I created
>>>> new variables:
>>>> 
>>>> ;; `comment-start' and `comment-end' assume there is only one type of
>>>> ;; comment, and that the comment spans only one line.  So they are not
>>>> ;; sufficient for our purpose.
>>> 
>>> ??? This is surprisingly unclean, IMO.  For starters, the names of the
>>> variables are confusing.  The need to define two sets of comment-start and
>>> comment-end regexps is also a nuisance and a source of errors.
>>> 
>>> How do non-treesit modes handle this issue?  Why do the treesit-based modes
>>> need something special here?
>>> 
>>> Stefan, any ideas?
>> 
>> `comment-start` and `comment-end` do not describe the set of possible
>> comment delimiters.  They describe the comment delimiters that should be
>> *inserted* when we do things like `comment-dwim`.
>> 
>> To find/match comment delimiters we have `comment-start-skip` and
>> `comment-end-skip`.  They're not ideal, but they've been good enough so far.
>> They don't say which comment starter matches which comment-ender (that
>> was done by the syntax-tables), but tree-sitter should be able to tell
>> us that when we need it.
>> 
>> It would be nice if we could avoid the need to set/use
>> `comment-start-skip` and `comment-end-skip` when using tree-sitter.
>> Maybe we can compute their values from the tree-sitter grammar.
>> But getting rid of uses of those vars will take a fair bit more work,
>> I think.
> 
> OK, but do you agree that adding yet another pair of variables,
> treesit-comment-start/end, is the opposite of what we want?

Yes. I removed them in d5dc1dbf7cb.

Yuan




^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-27 22:21                 ` Yuan Fu
@ 2022-11-28  0:24                   ` Stefan Kangas
  2022-11-28 13:59                   ` Eason Huang
  1 sibling, 0 replies; 15+ messages in thread
From: Stefan Kangas @ 2022-11-28  0:24 UTC (permalink / raw)
  To: Yuan Fu, Eli Zaretskii; +Cc: dev, aqua0210, Stefan Monnier, 59498, mardani29

Yuan Fu <casouri@gmail.com> writes:

>> OK, but do you agree that adding yet another pair of variables,
>> treesit-comment-start/end, is the opposite of what we want?
>
> Yes. I removed them in d5dc1dbf7cb.

I also think some documentation updates might be needed:

admin/notes/tree-sitter/html-manual/Parser_002dbased-Indentation.html
191: defined by regular expression <code>treesit-comment-end</code>
192: (see <a href="Tree_002dsitter-major-modes.html">treesit-comment-end</a>).
239: expression <code>treesit-comment-start</code> (see <a
href="Tree_002dsitter-major-modes.html">treesit-comment-start</a>).
This function assumes <var>parent</var> is
248: <code>treesit-comment-start</code>.  This function assumes
<var>parent</var> is

doc/lispref/modes.texi
4974: defined by regular expression @code{treesit-comment-end}
4975: (@pxref{Tree-sitter major modes, treesit-comment-end}).
5014: expression @code{treesit-comment-start} (@pxref{Tree-sitter major
5015: modes, treesit-comment-start}).  This function assumes @var{parent} is
5023: @code{treesit-comment-start}.  This function assumes @var{parent} is

doc/lispref/parsing.texi
1733: @defvar treesit-comment-start
1739: @defvar treesit-comment-end

lisp/treesit.el
1180:     Matches if text after point matches `treesit-comment-end'.
1215:     Returns the position after a match for `treesit-comment-start'.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled
  2022-11-27 22:21                 ` Yuan Fu
  2022-11-28  0:24                   ` Stefan Kangas
@ 2022-11-28 13:59                   ` Eason Huang
  1 sibling, 0 replies; 15+ messages in thread
From: Eason Huang @ 2022-11-28 13:59 UTC (permalink / raw)
  To: Yuan Fu; +Cc: dev, Eli Zaretskii, Stefan Monnier, 59498, mardani29

Yuan Fu <casouri@gmail.com> writes:

>> On Nov 26, 2022, at 11:24 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>>> Cc: Yuan Fu <casouri@gmail.com>,  dev@rjt.dev,  aqua0210@foxmail.com,
>>>  59498@debbugs.gnu.org,  mardani29@yahoo.es
>>> Date: Sun, 27 Nov 2022 02:18:06 -0500
>>>
>>>>> I added treesit-comment-start/end to help indenting comments. So this is
>>>>> the correct way to use them. The following comment explains why I created
>>>>> new variables:
>>>>>
>>>>> ;; `comment-start' and `comment-end' assume there is only one type of
>>>>> ;; comment, and that the comment spans only one line.  So they are not
>>>>> ;; sufficient for our purpose.
>>>>
>>>> ??? This is surprisingly unclean, IMO.  For starters, the names of the
>>>> variables are confusing.  The need to define two sets of comment-start and
>>>> comment-end regexps is also a nuisance and a source of errors.
>>>>
>>>> How do non-treesit modes handle this issue?  Why do the treesit-based modes
>>>> need something special here?
>>>>
>>>> Stefan, any ideas?
>>>
>>> `comment-start` and `comment-end` do not describe the set of possible
>>> comment delimiters.  They describe the comment delimiters that should be
>>> *inserted* when we do things like `comment-dwim`.
>>>
>>> To find/match comment delimiters we have `comment-start-skip` and
>>> `comment-end-skip`.  They're not ideal, but they've been good enough so far.
>>> They don't say which comment starter matches which comment-ender (that
>>> was done by the syntax-tables), but tree-sitter should be able to tell
>>> us that when we need it.
>>>
>>> It would be nice if we could avoid the need to set/use
>>> `comment-start-skip` and `comment-end-skip` when using tree-sitter.
>>> Maybe we can compute their values from the tree-sitter grammar.
>>> But getting rid of uses of those vars will take a fair bit more work,
>>> I think.
>>
>> OK, but do you agree that adding yet another pair of variables,
>> treesit-comment-start/end, is the opposite of what we want?
>
> Yes. I removed them in d5dc1dbf7cb.
>


Hi Yuan,

I build Emacs with the commit a85ff22300, which contain d5dc1dbf7cb,
I can confirm that the indent issue has been fixed.
Thanks you very much.

-- 
Eason Huang





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error  when enabled
       [not found] <m24juq9zn6.fsf@foxmail.com>
@ 2022-11-30 21:33 ` Yuan Fu
  0 siblings, 0 replies; 15+ messages in thread
From: Yuan Fu @ 2022-11-30 21:33 UTC (permalink / raw)
  To: aqua0210; +Cc: Randy Taylor, Eli Zaretskii, Stefan Monnier, 59498, mardani29


Eason Huang <aqua0210@foxmail.com> writes:

> Yuan Fu <casouri@gmail.com> writes:
>
>>> On Nov 26, 2022, at 11:24 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>
>>>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>>>> Cc: Yuan Fu <casouri@gmail.com>,  dev@rjt.dev,  aqua0210@foxmail.com,
>>>>  59498@debbugs.gnu.org,  mardani29@yahoo.es
>>>> Date: Sun, 27 Nov 2022 02:18:06 -0500
>>>>
>>>>>> I added treesit-comment-start/end to help indenting comments. So this is
>>>>>> the correct way to use them. The following comment explains why I created
>>>>>> new variables:
>>>>>>
>>>>>> ;; `comment-start' and `comment-end' assume there is only one type of
>>>>>> ;; comment, and that the comment spans only one line.  So they are not
>>>>>> ;; sufficient for our purpose.
>>>>>
>>>>> ??? This is surprisingly unclean, IMO.  For starters, the names of the
>>>>> variables are confusing.  The need to define two sets of comment-start and
>>>>> comment-end regexps is also a nuisance and a source of errors.
>>>>>
>>>>> How do non-treesit modes handle this issue?  Why do the treesit-based modes
>>>>> need something special here?
>>>>>
>>>>> Stefan, any ideas?
>>>>
>>>> `comment-start` and `comment-end` do not describe the set of possible
>>>> comment delimiters.  They describe the comment delimiters that should be
>>>> *inserted* when we do things like `comment-dwim`.
>>>>
>>>> To find/match comment delimiters we have `comment-start-skip` and
>>>> `comment-end-skip`.  They're not ideal, but they've been good enough so far.
>>>> They don't say which comment starter matches which comment-ender (that
>>>> was done by the syntax-tables), but tree-sitter should be able to tell
>>>> us that when we need it.
>>>>
>>>> It would be nice if we could avoid the need to set/use
>>>> `comment-start-skip` and `comment-end-skip` when using tree-sitter.
>>>> Maybe we can compute their values from the tree-sitter grammar.
>>>> But getting rid of uses of those vars will take a fair bit more work,
>>>> I think.
>>>
>>> OK, but do you agree that adding yet another pair of variables,
>>> treesit-comment-start/end, is the opposite of what we want?
>>
>> Yes. I removed them in d5dc1dbf7cb.
>>
>
>
> Hi Yuan,
>
> I build Emacs with the commit a85ff22300, which contain d5dc1dbf7cb,
> I can confirm that the indent issue has been fixed.
> Thanks you very much.

Thanks for verifying!

Yuan





^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2022-11-30 21:33 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-23  2:24 bug#59498: 29.0.50; c++-ts-mode get wrong-type-argument error when enabled Eason Huang
2022-11-23  8:44 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-23 10:53   ` Eason Huang
2022-11-24 14:39     ` Randy Taylor
2022-11-25 12:56       ` Eason Huang
2022-11-26 11:18       ` Eli Zaretskii
2022-11-26 22:11         ` Yuan Fu
2022-11-27  6:24           ` Eli Zaretskii
2022-11-27  7:18             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-27  7:24               ` Eli Zaretskii
2022-11-27 22:21                 ` Yuan Fu
2022-11-28  0:24                   ` Stefan Kangas
2022-11-28 13:59                   ` Eason Huang
2022-11-27 22:00               ` Yuan Fu
     [not found] <m24juq9zn6.fsf@foxmail.com>
2022-11-30 21:33 ` Yuan Fu

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).