GNU bug report logs - #61356
29.0.60; wrong-type-argument in treesit-indent-region when indenting a C buffer

Previous Next

To reply to this bug, email your comments to 61356 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Martín <mardani29 <at> yahoo.es>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.60; wrong-type-argument in treesit-indent-region when
 indenting a C buffer
Date: Tue, 07 Feb 2023 23:20:09 +0100

Steps to reproduce the problem:

emacs -Q
C-x C-f emacs/src/xdisp.c RET
M-x c-ts-mode RET
C-x h
TAB

Expected result:

The buffer is reindented.

Actual results:

The operation fails with this error:

Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  treesit-indent-region(1 1214226)
  indent-region(1 1214226)
  indent-for-tab-command(nil)
  funcall-interactively(indent-for-tab-command nil)
  call-interactively(indent-for-tab-command nil nil)
  command-execute(indent-for-tab-command)

Message #8 received at 61356 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Martín <mardani29 <at> yahoo.es>, Yuan Fu
 <casouri <at> gmail.com>, Theodor Thornhill <theo <at> thornhill.no>
Cc: 61356 <at> debbugs.gnu.org
Subject: Re: bug#61356: 29.0.60;
 wrong-type-argument in treesit-indent-region when indenting a C buffer
Date: Thu, 09 Feb 2023 12:20:45 +0200

> Date: Tue, 07 Feb 2023 23:20:09 +0100
> From:  Daniel Martín via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 
> Steps to reproduce the problem:
> 
> emacs -Q
> C-x C-f emacs/src/xdisp.c RET
> M-x c-ts-mode RET
> C-x h
> TAB
> 
> Expected result:
> 
> The buffer is reindented.
> 
> Actual results:
> 
> The operation fails with this error:
> 
> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
>   treesit-indent-region(1 1214226)
>   indent-region(1 1214226)
>   indent-for-tab-command(nil)
>   funcall-interactively(indent-for-tab-command nil)
>   call-interactively(indent-for-tab-command nil nil)
>   command-execute(indent-for-tab-command)

Thank you for your report.

Yuan and Theo, could you please look into this?  I briefly stepped
through the code involved in the problem, and it sounds like it makes
some assumptions regarding the nodes which are not necessarily true in
Real Life.

Message #11 received at 61356 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61356 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>,
 Theodor Thornhill <theo <at> thornhill.no>
Subject: Re: bug#61356: 29.0.60; wrong-type-argument in
 treesit-indent-region when indenting a C buffer
Date: Sat, 25 Feb 2023 03:24:54 +0100

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Tue, 07 Feb 2023 23:20:09 +0100
>> From:  Daniel Martín via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> 
>> Steps to reproduce the problem:
>> 
>> emacs -Q
>> C-x C-f emacs/src/xdisp.c RET
>> M-x c-ts-mode RET
>> C-x h
>> TAB
>> 
>> Expected result:
>> 
>> The buffer is reindented.
>> 
>> Actual results:
>> 
>> The operation fails with this error:
>> 
>> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
>>   treesit-indent-region(1 1214226)
>>   indent-region(1 1214226)
>>   indent-for-tab-command(nil)
>>   funcall-interactively(indent-for-tab-command nil)
>>   call-interactively(indent-for-tab-command nil nil)
>>   command-execute(indent-for-tab-command)
>
> Thank you for your report.
>
> Yuan and Theo, could you please look into this?  I briefly stepped
> through the code involved in the problem, and it sounds like it makes
> some assumptions regarding the nodes which are not necessarily true in
> Real Life.

c-ts-mode from the tip of the emacs-29 branch can indent xdisp.c without
failures if I apply the patch from bug#61691 and the patch attached to
this email message.

It is very slow, though, compared to c-mode.  I have a very fast machine
and it took around 10 minutes to indent the whole file, while c-mode
indented the file in 30-40 seconds.  I guess the algorithm in
treesit-indent-region doesn't scale very well for very big files like
xdisp.c.

[0001-Check-the-anchor-along-with-the-offset-in-treesit-in.patch (text/x-patch, attachment)]

Message #14 received at 61356 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 61356 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Theodor Thornhill <theo <at> thornhill.no>
Subject: Re: bug#61356: 29.0.60; wrong-type-argument in treesit-indent-region
 when indenting a C buffer
Date: Fri, 24 Feb 2023 21:21:11 -0800

> On Feb 24, 2023, at 6:24 PM, Daniel Martín <mardani29 <at> yahoo.es> wrote:
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>>> Date: Tue, 07 Feb 2023 23:20:09 +0100
>>> From:  Daniel Martín via "Bug reports for GNU Emacs,
>>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>> 
>>> 
>>> Steps to reproduce the problem:
>>> 
>>> emacs -Q
>>> C-x C-f emacs/src/xdisp.c RET
>>> M-x c-ts-mode RET
>>> C-x h
>>> TAB
>>> 
>>> Expected result:
>>> 
>>> The buffer is reindented.
>>> 
>>> Actual results:
>>> 
>>> The operation fails with this error:
>>> 
>>> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
>>>  treesit-indent-region(1 1214226)
>>>  indent-region(1 1214226)
>>>  indent-for-tab-command(nil)
>>>  funcall-interactively(indent-for-tab-command nil)
>>>  call-interactively(indent-for-tab-command nil nil)
>>>  command-execute(indent-for-tab-command)
>> 
>> Thank you for your report.
>> 
>> Yuan and Theo, could you please look into this?  I briefly stepped
>> through the code involved in the problem, and it sounds like it makes
>> some assumptions regarding the nodes which are not necessarily true in
>> Real Life.
> 
> c-ts-mode from the tip of the emacs-29 branch can indent xdisp.c without
> failures if I apply the patch from bug#61691 and the patch attached to
> this email message.
> 
> It is very slow, though, compared to c-mode.  I have a very fast machine
> and it took around 10 minutes to indent the whole file, while c-mode
> indented the file in 30-40 seconds.  I guess the algorithm in
> treesit-indent-region doesn't scale very well for very big files like
> xdisp.c.
> 

Thanks, I applied the patch. What you observed is certainly a regression due to, from what I can see from profiling, c-ts-common-statement-offset. It is added for more accurate indenting, by going up the parse tree and “count brackets”, more or less. This is probably a pretty inefficient when calculating indentation for every line. A change I just pushed helps a bit (in a block, make the first child calculate indentation as before, and children after than uses the previous sibling’s indentation), but still not enough.

I have some ideas to improve this, and get back once I have something.

Yuan

Message #17 received at 61356 <at> debbugs.gnu.org (full text, mbox):

From: stefankangas <at> gmail.com
To: Yuan Fu <casouri <at> gmail.com>
Cc: 61356 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Theodor Thornhill <theo <at> thornhill.no>,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#61356: 29.0.60; wrong-type-argument in treesit-indent-region
 when indenting a C buffer
Date: Mon, 4 Sep 2023 12:47:13 -0700

Yuan Fu <casouri <at> gmail.com> writes:

> Thanks, I applied the patch. What you observed is certainly a regression due to,
> from what I can see from profiling, c-ts-common-statement-offset. It is added
> for more accurate indenting, by going up the parse tree and “count brackets”,
> more or less. This is probably a pretty inefficient when calculating indentation
> for every line. A change I just pushed helps a bit (in a block, make the first
> child calculate indentation as before, and children after than uses the previous
> sibling’s indentation), but still not enough.
>
> I have some ideas to improve this, and get back once I have something.

It seems like the patch here was applied.  Can this bug therefore be
closed, or is there more to do here?

Previous Next

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