bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets
Date: Fri, 24 Nov 2023 09:23:29 +0200

> Date: Thu, 23 Nov 2023 12:55:31 -0800
> From:  Arteen Abrishami via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> This is specifically for the usage of `c-ts-mode` and is not a problem
> in `c-mode`. Sometimes, when you type something like:
> 
> else
> break
> 
> it won't indent the "break" until you type a semicolon. In this below
> scenario, it does not indent the break at all, but `c-mode` does, and
> switching from `c-mode` to `c-ts-mode` with correct indentation leaves
> it fixed, but `c-ts-mode` cannot detect or fix it itself.
> 
> You can put it into a `.c` buffer all by itself and see:
> 
> ```
> unsigned
> heap_pop(struct heapq * heap)
> {
>   if (heap->sz == 0)
>     return -1;
> 
>   unsigned ret_val = heap->vals[0];
>   heap->vals[0] = heap->vals[heap->len];
>   heap->len -= 1;
>   unsigned i = 0;
>   unsigned lc;
> 
>   while ((lc = HEAPQ_L_CHILD(i)) < heap->len)
>     {
>       unsigned rc = HEAPQ_R_CHILD(i);
>       /* no right child for our guy, special case */      
>       if (rc == heap->len)
>         {
>           if (heap->vals[lc] < heap->vals[i])
>             SWAP(heap->vals[lc], heap->vals[i]);
>           break;
>         }
> 
>       if (heap->vals[lc] < heap->vals[i])
>         {
>           SWAP(heap->vals[lc], heap->vals[i]);
>           i = lc;
>         }
>       else if (heap->vals[rc] < heap->vals[i])
>         {
>           SWAP(heap->vals[rc], heap->vals[i]);
>           i = rc;
>         }
>       else
>       break;
>       
>     }
> }
> ```
> 
> The very last break on the else without brackets around it will not indent.c

Yuan, any comments?

My personal take on this is that as long as typing the required
semi-colons fixes the indentation, we are okay in these cases, but if
we can do better (i.e. if the problem is not that tree-sitter returns
a tree with an error node), we should fix this even without relying on
the electric semi-colon.

In the specific example above, it looks like tree-sitter does succeed
in parsing and shows a valid tree:

           alternative: 
            (else_clause else
             (break_statement break ;)))))

So I wonder why we don't indent the "break;" part here.

Comparison with c-mode is not relevant here, btw, since c-mode uses a
very different strategy for computing indentation.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]