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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: sadiq <at> sadiqpk.org, 65006 <at> debbugs.gnu.org
Subject: bug#65006: 29.1.50; c-ts-mode: else block not indented right on TAB
Date: Thu, 03 Aug 2023 09:37:49 +0300

> From: Yuan Fu <casouri <at> gmail.com>
> Date: Wed, 2 Aug 2023 17:45:10 -0700
> Cc: Mohammed Sadiq <sadiq <at> sadiqpk.org>,
>  65006 <at> debbugs.gnu.org
> 
> > 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 :-(

Maybe we should track all those discussions, and voice our opinion
against changes whose reasons are not strong enough to justify
breakage?  For example, this particular PR was around since Sep 2022,
so we should have had ample time to voice our objections.

OTOH, they say that parsers for other languages already have
else_clause in their grammars.  So maybe this change is somewhat to
the better, at least when features common to several languages are
considered?

And anyway, this again raises the issue of Someone™ volunteering to
keep track of these developments.  We already have 14 TS-based modes
in Emacs (on master), so this is not a trivial job, I think.

> > 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.

Given that the change doesn't affect old parsers, please install on
the emacs-29 branch as soon as you are okay with the changes.

> >> 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.

I agree that we have a problem here.  The only question is how to
solve it in a reasonable way that will hold given our development and
release schedules, and given the schedules of users and distros
upgrading the Emacs versions.

Previous Next

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