From: Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 61502@debbugs.gnu.org, casouri@gmail.com, pankaj@codeisgreat.org
Subject: bug#61502: 29.0.60; c-ts-mode auto-indent not working
Date: Tue, 14 Feb 2023 21:21:33 +0100 [thread overview]
Message-ID: <875yc40zhu.fsf@thornhill.no> (raw)
In-Reply-To: <83a61gc8xx.fsf@gnu.org>
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: 61502@debbugs.gnu.org
>> Date: Tue, 14 Feb 2023 20:41:04 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Keep typing whatever code you wan "int main" to include, and it will
>> > auto-indent soon enough.
>>
>> Yeah, but.
>
> My point is that what we are used to from CC mode does not necessarily
> have to work the same way with tree-sitter based modes. As long as
> the indentation fixes itself soon enough, we are still fine, I think.
>
>> int
>> main
>> {
>> for (;;)
>> {|
>> }
>> ```
>>
>> If you press RET if point at | you'll see we indent immediately, even
>> though there is no closing bracket. This is because of how
>> treesit-indent defaults to treesit-node-on when there is no node at
>> point. So in the example without the for loop the parent is then set to
>> whatever treesit-node-on returns, which in this case is the root
>> node. That means that the rule for translation_unit is selected, which
>> is:
>>
>> `(((parent-is "translation_unit") point-min 0)
>>
>> However, what's interesting here is that treesit-indent selects an
>> "unexisting" node as the "smallest-node". Specifically that is:
>>
>> #<treesit-node "}" in 13-13>
>>
>> This node in turn will return "compound_statement" if you look for its
>> parent. It seems some parsers detects these nodes, so maybe we should
>> add some handling for that? Some "block-closers" code in
>> treesit-node-on, so that treesit-node-on doesn't default to the root
>> node, but rather the compound_statement?
>
> AFAIU, you are talking about hitting RET in the following situation
> (where "|" stands for point):
>
> int main ()
> {|
> }
>
> However, the OP presented a slightly different situation:
>
> int main ()
> {|
>
> That is, without the closing brace. In that case, there's no "}" in
> the source. Are you saying that the tree-sitter's parser "invents"
> such a node?
That's correct. In tree-sitter-c at least that's the case.
>
> And why does treesit-indent select that "unexisting" node in the first
> place?
>
This code:
(smallest-node
(cond ((null (treesit-parser-list)) nil)
((eq 1 (length (treesit-parser-list)))
(treesit-node-at bol))
((treesit-language-at (point))
(treesit-node-at bol (treesit-language-at (point))))
(t (treesit-node-at bol))))
treesit-node-at selects the "invented" node.
>> I'm not sure this explanation was easy to follow at all, but I'll add a
>> hack in a diff to make the point hopefully a little clearer.
>>
>> What do you think?
>
> How well did you test that?
Not well at all. I just created that hack to make the example a little
clearer. I think the change probably should go into treesit-node-on.
> Does it fix similar problems with struct
> definition at top-level? Are there any regressions elsewhere in the
> indentation?
Not that I found, but I'll experiment some more.
>
> There are also other similar cases, but with code on deeper levels.
> Try this, for example (where "|" again stands for point):
>
> int
> main
> {
> for (;;)|
> }
>
> Now press RET and observe the result:
>
> int
> main
> {
> for (;;)
> |
> }
>
> instead of the expected
>
> int
> main
> {
> for (;;)
> |
> }
>
> Why?
If I'm not mistaken the same "problem". Treesit-node-on selects the
surrounding compound_statement, so it only indents one step from column 0.
>
> (Of course, as soon as you type ";", the code is automatically
> reindented to yield the correct indentation. Which was my point.)
Yeah, but consider the same example of yours without the closing brace:
```
int
main
{
for (;;)|
```
Now type RET
```
int
main
{
for (;;)
|
```
Now type {
```
int
main
{
for (;;)
{|
```
Now type RET
```
int
main
{
for (;;)
{
|
```
Which is what I consider a little confusing. We get different
indentation with and without the closed scope.
Theo
next prev parent reply other threads:[~2023-02-14 20:21 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 [this message]
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
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=875yc40zhu.fsf@thornhill.no \
--to=bug-gnu-emacs@gnu.org \
--cc=61502@debbugs.gnu.org \
--cc=casouri@gmail.com \
--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).