bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets

[Dmitry Gutov]

On 28/11/2023 08:55, Yuan Fu wrote:
> On 11/26/23 6:22 PM, Dmitry Gutov wrote:
> > On 27/11/2023 03:47, Yuan Fu wrote:
> > > I pushed two commits which should fix the indentation for "break" 
> > > after "else", and indentation for empty lines after if/else/for/while 
> > > in general. The fix for the general case doesn't use the parse tree, 
> > > since the parse tree is often incomplete when you type if (...) and 
> > > hit return. Instead it uses a plain regexp match to see if the 
> > > previous line starts with if/else/for/while. This seems like a 
> > > reasonable heuristic to use before user types more things, at which 
> > > point more accurate indentation rules would be used, since the parse 
> > > tree should be more complete then.
> >
> > Sorry, two counter-examples right away:
> >
> > Type 'elsewhere();' and RET -> the next line is indented 1 level 
> > extra, at least until you type some more and then have the line 
> > reindented either with pressing TAB or adding semicolon.
> >
> > Type 'for (;;) {}' and RET -> same.
> >
> > The first case is easy to guard against (just check that the next char 
> > is either space of opening paren), but the second one less so. OTOH, 
> > the second case is likely to have a parse tree without errors, so if 
> > we also check for that... the heuristic might work.
>
> Well, darn it. And you're right, the second case is a bit hard to 
> check... Well I guess for the moment we can remove this heuristic. (I 
> tried a bit, and checking for no errors is not so easy.)

Maybe it's possible to salvage this heuristic a bit, at least for 
"else", and as long as it's followed by "}" somewhere (e.g. when 
electric-pair-mode is used).

diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index 31a9d0fc886..20689dc1862 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -373,8 +373,17 @@ c-ts-mode--indent-styles
            ;; point on the empty line to be indented; this rule
            ;; does that.
            ((and no-node
+                 ;; Could be a matcher 'prev-sibling-p'.
+                 (lambda (_ parent bol &rest _)
+                   (equal
+                    "ERROR"
+                    (treesit-node-type
+                     (treesit-node-prev-sibling
+                      (treesit-node-first-child-for-pos
+                       parent bol)
+                      t))))
                  (c-ts-mode--prev-line-match
-                  ,(rx (or "if" "else" "while" "do" "for"))))
+                  ,(rx "else" symbol-end)))
             prev-line c-ts-mode-indent-offset)

            ((parent-is "translation_unit") column-0 0)

The rest of the nodes (if/while/do/for) don't result in parse errors 
here, as long as the condition in parentheses is typed out correctly.

I tried some additional clauses looking for "previous sibling", checking 
whether it's for_statement, etc, which ends with "expression statement", 
and that one is empty... but it a fair amount of code which will likely 
miss other edge cases anyway. Or breaks when the grammar changes.