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

Previous Next

Full log

Message #20 received at 65006 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Mohammed Sadiq <sadiq <at> sadiqpk.org>, 65006 <at> debbugs.gnu.org
Subject: Re: 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 <at> gnu.org> wrote:
> 
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Wed, 2 Aug 2023 09:46:54 -0700
>> Cc: Mohammed Sadiq <sadiq <at> sadiqpk.org>,
>> 65006 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.