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>,
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: Tue, 14 Feb 2023 20:41:04 +0100 [thread overview]
Message-ID: <87edqs11db.fsf@thornhill.no> (raw)
In-Reply-To: <83a61ge69s.fsf@gnu.org>
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Pankaj Jangid <pankaj@codeisgreat.org>
>> Date: Tue, 14 Feb 2023 10:06:13 +0530
>>
>>
>> The auto-indent is not working when using c-ts-mode.
>>
>> Steps:
>>
>> 1. create a new file test.c
>>
>> 2. After typing following snippet, the indentation should work
>> automatically on RET. But even the TAB is not indenting the next line
>> (after the RET),
>>
>> --8<---------------cut here---------------start------------->8---
>> int main()
>> {
>> --8<---------------cut here---------------end--------------->8---
>
> Keep typing whatever code you wan "int main" to include, and it will
> auto-indent soon enough.
Yeah, but.
>
> So I'm not sure your expectations are necessarily true; they could be
> just something you are used to in CC mode. But I'll let Yuan and Theo
> chime in and tell whether a single RET here is supposed to
> auto-indent. Does c-ts-mode really always reindents on RET?
I agree this is a little unexpected. Let's consider this code:
```
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?
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?
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))))
next prev parent reply other threads:[~2023-02-14 19:41 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87edqs11db.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.