Subject: bug#59693: closed (Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 10 Dec 2022 01:42:02 +0000

Your bug report

#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
59693: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59693
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly
From: Yuan Fu <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Fri, 9 Dec 2022 17:41:04 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

Eli Zaretskii <[email-masked]> writes:

>> From: Yuan Fu <[email-masked]>
>> Date: Wed, 7 Dec 2022 15:13:19 -0800
>> Cc: Stefan Monnier <[email-masked]>,
>>  [email-masked],
>>  [email-masked]
>> 
>> >> 1. Only allow base buffer to have parsers, no change is needed
>> >> for insdel.c, treesit_record_change can find the base buffer and
>> >> update its parsers. We can ask indirect buffers to use their base
>> >> buffer’s parser. Unless the base buffer is narrowed, I think it
>> >> will work fine.
>> > 
>> > I think this is fine, but we need to document it.
>> > 
>> >> I remember that there were a discussion along the lines of user-narrow vs low-level narrow, what was the outcome of that discussion?
>> > 
>> > Nothing in particular, and I don't think it's relevant.  If some mode needs
>> > to widen, it can.
>> > 
>> > Thanks.
>> 
>> Here is a patch that does #1.
>
> Thanks, a few minor comments for documentation below.
>
>> +If @var{buffer} (or the current buffer) is an indirect buffer, its
>> +base buffer is used instead.  That is, indirect buffers uses their
>                                           ^^^^^^^^^^^^^^^^^^^^^
> "use", in plural.
>
>> @@ -447,7 +455,9 @@ Using Parser
>>  @defun treesit-parser-list &optional buffer
>>  This function returns the parser list of @var{buffer}.  If
>>  @var{buffer} is @code{nil} or omitted, it defaults to the current
>> -buffer.
>> +buffer.  If @var{buffer} (or the current buffer) is an indirect
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I'd say more concisely
>
>   If that buffer is an indirect buffer, ...
>
> And please add a cross-reference to the node where indirect buffers
> are described.
>
>> +buffer, its base buffer is used instead.  That is, indirect buffers
>> +uses their base buffer's parsers.
>    ^^^^
> "use".
>
>> +   Parsers in indirect buffers: We make indirect buffers to share the
>> +   parser of its base buffer.  See bug#59693 for reasoning.  */
>
> I'd rather have a short summary of the reasoning here than ask the
> readers to go to the bug tracker and read a long discussion.  Just
> explain why indirect buffers present a problem for a parser, and then
> say that we decided to do this as the easiest, simplest solution.
>
>> +If BUFFER (or the current buffer) is an indirect buffer, its base
>> +buffer is used instead.  That is, indirect buffers uses their base
>                                                       ^^^^
> "use"
>
>> +buffer's parsers.  If the base buffer is narrowed, an indirect buffer
>> +might not be able to retrieve information of the portion of the buffer
>> +text that are invisible in the base buffer.  Lisp programs should
>> +widen as necessary should they want to use a parser in an indirect
>> +buffer.  */)
>
> Here I would remove the second sentence: it is appropriate for the
> manual, but is redundant in the doc string, since the next sentence
> says it all.
>
>> @@ -1329,7 +1345,10 @@ DEFUN ("treesit-parser-list",
>>         Ftreesit_parser_list, Streesit_parser_list,
>>         0, 1, 0,
>>         doc: /* Return BUFFER's parser list.
>> -BUFFER defaults to the current buffer.  */)
>> +
>> +BUFFER defaults to the current buffer.  If BUFFER (or the current
>> +buffer) is an indirect buffer, its base buffer is used instead.  That
>> +is, indirect buffers uses their base buffer's parsers.  */)
>                         ^^^^
> "use"
>
> Otherwise, LGTM.

Cool, I fixed those and pushed.

Yuan

Subject: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly
From: [email-masked]
To: [email-masked]
Date: Tue, 29 Nov 2022 21:21:29 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

    *** Welcome to IELM ***  Type (describe-mode) or press C-h m for help.
    ELISP> (set-buffer (get-buffer-create "a"))
    ELISP> (insert "int main();")
    ELISP> (require 'treesit)
    ELISP> (treesit-node-children (treesit-node-child (treesit-buffer-root-node 'c) 0))
    (#<treesit-node
      (primitive_type)
      in 1-4> #<treesit-node
      (function_declarator)
      in 5-11> #<treesit-node ";" in 11-12>)

This is expected

    ELISP> (set-buffer (make-indirect-buffer "a" "b"))
    ELISP> (goto-char (point-min))
    ELISP> (insert " ")
    ELISP> (set-buffer "a")
    ELISP> (buffer-string)
    " int main();"

    ELISP> (treesit-node-children (treesit-node-child (treesit-buffer-root-node 'c) 0))
    (#<treesit-node
      (primitive_type)
      in 1-4> #<treesit-node
      (function_declarator)
      in 5-11> #<treesit-node
      (ERROR)
      in 11-12> #<treesit-node ";" in 12-13>)

This is unexpected. If we had called '(insert " ")' in the base buffer
"a", we would have got

    (#<treesit-node
      (primitive_type)
      in 2-5> #<treesit-node
      (function_declarator)
      in 6-12> #<treesit-node ";" in 12-13>)

Thanks for your hard work.