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

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

bug#65006: 29.1.50; c-ts-mode: else block not indented right on TAB


From: Yuan Fu
Subject: bug#65006: 29.1.50; c-ts-mode: else block not indented right on TAB
Date: Wed, 2 Aug 2023 17:45:10 -0700


> On Aug 2, 2023, at 10:05 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Wed, 2 Aug 2023 09:46:54 -0700
>> Cc: Mohammed Sadiq <sadiq@sadiqpk.org>,
>> 65006@debbugs.gnu.org
>> 
>>>> afair, this did seem to work in the past.  May be this
>>>> happened after I updated treesitter-c module, idk.
>> 
>> Yeah, (sign) I can reproduce this with the latest tree-sitter-c grammar but 
>> not the old one. Someone decides to add an else_clause node into the grammar 
>> [1] two weeks ago.
> 
> How was the else clause parsed in the previous versions of the
> grammar?

It used to be something like this:

   (if_statement
     if
     condition: (xxx)
     consequence:  (xxx)
     else
     alternative: (xxx))

Now it’s like this:

   (if_statement
     if
     condition: (xxx)
     consequence:  (xxx)
     alternative: 
      (else_clause else
       (xxx)))

For the reason of the change, you can check out the link in my previous email. 
The justification is IMO insubstantial, to say the least :-(

> Will the proposed fix work with the older versions of the grammar?

Yes

>>> Yuan, can you look into this, please?
>> 
>> Should the fix go into emacs-29 or master?
> 
> To emacs-29, please.

Ok.

>> We really need some way to mandate a version of grammar. These breaking 
>> changes are far more frequent than I originally thought.
> 
> Who will track all those versions and record which ones are supported?
> And many grammar libraries don't have versions at all, so we will have
> to track commits instead.

We can request tree-sitter to add versioning to languages, which won’t happen 
any time soon; or we can pin the commits (which is what neovim does), but I 
know that’s against our policy. I don’t really have a good solution. But having 
our packages randomly break all the time is bad, and keep adapting all these 
breaking changes is also a significant burden on Emacs maintainers. And the 
speed in which we fix these breakages can never match the speed in which they 
bring them.

Yuan




reply via email to

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