From: Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>, Eli Zaretskii <eliz@gnu.org>,
Pankaj Jangid <pankaj@codeisgreat.org>,
Yuan Fu <casouri@gmail.com>
Cc: 61502@debbugs.gnu.org
Subject: bug#61502: 29.0.60; c-ts-mode auto-indent not working
Date: Wed, 15 Feb 2023 07:07:59 +0100 [thread overview]
Message-ID: <B4DA2392-C74E-49D7-B2F4-77E672C3FFDE@thornhill.no> (raw)
In-Reply-To: <67e055d8-c709-df09-374e-560057f61731@yandex.ru>
On 15 February 2023 00:57:17 CET, Dmitry Gutov <dgutov@yandex.ru> wrote:
>On 14/02/2023 21:41, Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
>> What do you think?
>>
>> Theo
>>
>>
>> diff --git a/lisp/treesit.el b/lisp/treesit.el
>> index 749781894b..300a703515 100644
>> --- a/lisp/treesit.el
>> +++ b/lisp/treesit.el
>> @@ -1418,6 +1418,8 @@ treesit--indent-1
>> ;; encompass the whitespace.
>> (parent (cond ((and node parser)
>> (treesit-node-parent node))
>> + ((equal (treesit-node-type smallest-node) "}")
>> + (treesit-node-parent smallest-node))
>> (t (treesit-node-on bol bol)))))
>> (funcall treesit-indent-function node parent bol))))
>
>Here's a counter-example for this patch:
>
>int
>main ()
>{}|
>
>press RET at |, and you'll see the next line indented by 2 spaces. Whereas it shouldn't. This happens, among other things, because the added code doesn't distinguish between "real" and "virtual" nodes.
>
>BTW, in this example:
>
>int
>main
>{
> for (;;)
> {|
>}
>
>the "}" node selected by treesit--indent-1 is not "unexisting": it selects the closer on the next line, which is parsed to be the part of the "for" node. Thanks to its presence, the parent compound_statement node contains the point, and everything works out.
>
>And this one
>
>int
>main
>{
> for (;;)|
>}
>
>isn't fixed with your patch because the "unexisting" node in place is a different one: "expression_statement", and it has no closers. And it's "virtually" placed at the end of the previous line by the parser.
>
>So in most cases if the user has electric-pair-mode on, indentation should work okay. Without a pairing solution, though, we see different grammars handling incomplete code in different ways for different syntactic elements: virtual nodes, container nodes that span after point, container nodes that don't span after point, statements that parse into a different node type (usually wrapped in ERROR). We could report these one by one, hoping for the best. I'm curious how different editors fare with indentation in these conditions -- perhaps they use a different, more error-proof approach. But it could be that their uses are less fussy about indentation than we are.
Sure, i agree - the patch was not a change request, merely an example to show why the root node was chosen rather than the closer compound_statement node.
prev parent reply other threads:[~2023-02-15 6:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-14 4:36 bug#61502: 29.0.60; c-ts-mode auto-indent not working Pankaj Jangid
2023-02-14 13:16 ` Eli Zaretskii
2023-02-14 19:41 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-14 20:02 ` Eli Zaretskii
2023-02-14 20:21 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-15 12:24 ` Eli Zaretskii
2023-02-15 12:41 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-15 13:35 ` Dmitry Gutov
2023-02-15 14:03 ` Eli Zaretskii
2023-02-15 14:21 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-15 14:27 ` Eli Zaretskii
2023-02-15 14:53 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-15 15:02 ` Eli Zaretskii
2023-02-15 15:48 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-15 15:57 ` Dmitry Gutov
2023-02-15 17:11 ` Eli Zaretskii
2023-02-15 17:57 ` Dmitry Gutov
2023-02-15 18:11 ` Eli Zaretskii
2023-02-15 18:18 ` Dmitry Gutov
2023-02-15 17:09 ` Eli Zaretskii
2023-02-15 17:14 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-15 17:30 ` Eli Zaretskii
2023-02-15 17:52 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-14 20:59 ` Dmitry Gutov
2023-02-14 21:00 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-15 0:12 ` Dmitry Gutov
2023-02-14 23:57 ` Dmitry Gutov
2023-02-15 6:07 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B4DA2392-C74E-49D7-B2F4-77E672C3FFDE@thornhill.no \
--to=bug-gnu-emacs@gnu.org \
--cc=61502@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=pankaj@codeisgreat.org \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).