GNU bug report logs - #62717
29.0.60; c-ts-mode does not indent the first line in a function after RET

Previous Next

Full log

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: casouri <at> gmail.com, theo <at> thornhill.no, 62717 <at> debbugs.gnu.org,
 mardani29 <at> yahoo.es, joaotavora <at> gmail.com, acm <at> muc.de
Subject: Re: bug#62717: 29.0.60; c-ts-mode does not indent the first line in a
 function after RET
Date: Sun, 9 Apr 2023 19:33:20 +0300

On 09/04/2023 08:19, Eli Zaretskii wrote:
>> Cc: Theodor Thornhill<theo <at> thornhill.no>, Yuan Fu<casouri <at> gmail.com>,
>>   62717 <at> debbugs.gnu.org,
>>   João Távora<joaotavora <at> gmail.com>,
>>   Alan Mackenzie<acm <at> muc.de>
>> Date: Sun, 9 Apr 2023 03:20:23 +0300
>> From: Dmitry Gutov<dmitry <at> gutov.dev>
>>
>> What does this mean for us? Short of reimplementing nvim-treesitter's
>> algorithm (and I haven't read Atom's or Zed's indentation code;
>> anybody's welcome to chime in with a summary of either), we could just
>> install the patch at the end of this message: it fixes this particular
>> case, in a bit hackish way, but at least it doesn't affect other languages.
>>
>> Note that it still doesn't fix very similar cases, e.g.
>>
>>     int main () {
>>       for (;;) {<RET>
>>
>> (we need additional rules looking for ERROR nodes, like in nvim's
>> indent.scm), but in does fix
>>
>>     int main () {
>>       for (;;) {}<RET>
>>
>> and
>>
>>     int main () {
>>       int foo;<RET>
>>
>> I'm not sure, though, what is the big deal with adding the top-level
>> function's closing curly first thing before writing the body (after that
>> the parser starts working much better), so as far as I'm concerned this
>> patch is very optional. It does add some complexity, after all.
> If the patch solves some of the problems, passes the test suite, and
> doesn't introduce any regressions you see, I think you should install
> it (unless someone here objects).

With this kind of change, it's hard to judge regression potential in 
advance. I don't really write C/C++ myself with any regularity. And our 
test suite doesn't really work incomplete parse trees, I think.

So if we want this in emacs-29, I think someone interested should try 
running with this patch applied, at least for a little bit. Maybe just 
wait for a couple of days, if Daniel is testing it already.

Previous Next

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