GNU bug report logs -
#59693
29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly
Previous Next
Reported by: miha <at> kamnitnik.top
Date: Tue, 29 Nov 2022 20:21:01 UTC
Severity: normal
Found in version 29.0.50
Done: Yuan Fu <casouri <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 59693 <at> debbugs.gnu.org.
--
59693: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59693
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Wed, 7 Dec 2022 15:13:19 -0800
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
>> 59693 <at> debbugs.gnu.org,
>> miha <at> kamnitnik.top
>>
>> >> 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
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
*** 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.
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 2 years and 163 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.