GNU bug report logs - #60888
29.0.60; Lost c-or-c++-ts-mode

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Tue, 17 Jan 2023 17:35:03 UTC

Severity: normal

Fixed in version 29.0.60

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60888 in the body.
You can then email your comments to 60888 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#60888; Package emacs. (Tue, 17 Jan 2023 17:35:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Juri Linkov <juri <at> linkov.net>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 17 Jan 2023 17:35:03 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.60; Lost c-or-c++-ts-mode
Date: Tue, 17 Jan 2023 19:20:50 +0200
I started to rely on c-or-c++-ts-mode because there is no other replacement
to use for such mappings in init files:

  (when (and (treesit-ready-p 'c t) (treesit-ready-p 'cpp t))
    (add-to-list 'major-mode-remap-alist '(c-or-c++-mode . c-or-c++-ts-mode)))

c-or-c++-mode is activated for all .h files, so there should be the corresponding
c-or-c++-ts-mode, but it's lost somewhere in emacs-29.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60888; Package emacs. (Tue, 17 Jan 2023 18:23:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>, 60888 <at> debbugs.gnu.org
Subject: Re: bug#60888: 29.0.60; Lost c-or-c++-ts-mode
Date: Tue, 17 Jan 2023 20:22:39 +0200
On 17/01/2023 19:20, Juri Linkov wrote:
> I started to rely on c-or-c++-ts-mode because there is no other replacement
> to use for such mappings in init files:
> 
>    (when (and (treesit-ready-p 'c t) (treesit-ready-p 'cpp t))
>      (add-to-list 'major-mode-remap-alist '(c-or-c++-mode . c-or-c++-ts-mode)))
> 
> c-or-c++-mode is activated for all .h files, so there should be the corresponding
> c-or-c++-ts-mode, but it's lost somewhere in emacs-29.

Apparently it was decided that it's a new feature, and thus too late for 
emacs-29.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60888; Package emacs. (Thu, 19 Jan 2023 21:58:01 GMT) Full text and rfc822 format available.

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

From: Yuan Fu <casouri <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 60888 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#60888: 29.0.60; Lost c-or-c++-ts-mode
Date: Thu, 19 Jan 2023 13:57:17 -0800
Dmitry Gutov <dgutov <at> yandex.ru> writes:

> On 17/01/2023 19:20, Juri Linkov wrote:
>> I started to rely on c-or-c++-ts-mode because there is no other replacement
>> to use for such mappings in init files:
>>    (when (and (treesit-ready-p 'c t) (treesit-ready-p 'cpp t))
>>      (add-to-list 'major-mode-remap-alist '(c-or-c++-mode . c-or-c++-ts-mode)))
>> c-or-c++-mode is activated for all .h files, so there should be the
>> corresponding
>> c-or-c++-ts-mode, but it's lost somewhere in emacs-29.
>
> Apparently it was decided that it's a new feature, and thus too late
> for emacs-29.

I added it back. It really is a bug preventing one to use c(++)-ts-mode
on header files. So this should be fine to add. Plus I mostly just
copy-pasted from cc-mode. Sorry for the back-and-forth.

Yuan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60888; Package emacs. (Fri, 20 Jan 2023 08:21:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 60888 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#60888: 29.0.60; Lost c-or-c++-ts-mode
Date: Fri, 20 Jan 2023 09:57:09 +0200
close 60882 29.0.60
close 60888 29.0.60
thanks

>>> I started to rely on c-or-c++-ts-mode because there is no other replacement
>>> to use for such mappings in init files:
>>>    (when (and (treesit-ready-p 'c t) (treesit-ready-p 'cpp t))
>>>      (add-to-list 'major-mode-remap-alist '(c-or-c++-mode . c-or-c++-ts-mode)))
>>> c-or-c++-mode is activated for all .h files, so there should be the
>>> corresponding
>>> c-or-c++-ts-mode, but it's lost somewhere in emacs-29.
>>
>> Apparently it was decided that it's a new feature, and thus too late
>> for emacs-29.
>
> I added it back. It really is a bug preventing one to use c(++)-ts-mode
> on header files. So this should be fine to add. Plus I mostly just
> copy-pasted from cc-mode. Sorry for the back-and-forth.

Thanks, so now closing.

PS: It's nice that you added such instructions to the commentary and docstrings:

  ;; (add-to-list 'major-mode-remap-alist '(c-or-c++-mode . c-or-c++-ts-mode))

Maybe it should be sufficient for emacs-29 and better than updating
user's auto-mode-alist automatically.




bug marked as fixed in version 29.0.60, send any further explanations to 60888 <at> debbugs.gnu.org and Juri Linkov <juri <at> linkov.net> Request was from Juri Linkov <juri <at> linkov.net> to control <at> debbugs.gnu.org. (Fri, 20 Jan 2023 08:21:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60888; Package emacs. (Fri, 20 Jan 2023 08:40:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 60888 <at> debbugs.gnu.org, juri <at> linkov.net, dgutov <at> yandex.ru
Subject: Re: bug#60888: 29.0.60; Lost c-or-c++-ts-mode
Date: Fri, 20 Jan 2023 10:38:28 +0200
> Cc: 60888 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
> From: Yuan Fu <casouri <at> gmail.com>
> Date: Thu, 19 Jan 2023 13:57:17 -0800
> 
> 
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
> 
> > On 17/01/2023 19:20, Juri Linkov wrote:
> >> I started to rely on c-or-c++-ts-mode because there is no other replacement
> >> to use for such mappings in init files:
> >>    (when (and (treesit-ready-p 'c t) (treesit-ready-p 'cpp t))
> >>      (add-to-list 'major-mode-remap-alist '(c-or-c++-mode . c-or-c++-ts-mode)))
> >> c-or-c++-mode is activated for all .h files, so there should be the
> >> corresponding
> >> c-or-c++-ts-mode, but it's lost somewhere in emacs-29.
> >
> > Apparently it was decided that it's a new feature, and thus too late
> > for emacs-29.
> 
> I added it back. It really is a bug preventing one to use c(++)-ts-mode
> on header files. So this should be fine to add. Plus I mostly just
> copy-pasted from cc-mode. Sorry for the back-and-forth.

Yuan, something is still amiss here: there's a difference in the
decision whether C or C++ mode should be used between c-or-c++-mode
and c-or-c++-ts-mode.  For example, visit the file
dwarf2/line-header.h file from the recent GDB tree: c-or-c++-mode
decides (correctly) that it's C++, but c-or-c++-ts-mode decides that
it's C.

In general, try header files from GDB: GDB is written in C++, but many
*.h files kept their original *.h names, so you have a lot of testing
cases there.  I see quite a few of them where c-or-c++-ts-mode decides
incorrectly for some reason.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60888; Package emacs. (Fri, 20 Jan 2023 22:20:01 GMT) Full text and rfc822 format available.

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

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60888 <at> debbugs.gnu.org, juri <at> linkov.net, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#60888: 29.0.60; Lost c-or-c++-ts-mode
Date: Fri, 20 Jan 2023 14:19:35 -0800

> On Jan 20, 2023, at 12:38 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> Cc: 60888 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Thu, 19 Jan 2023 13:57:17 -0800
>> 
>> 
>> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>> 
>>> On 17/01/2023 19:20, Juri Linkov wrote:
>>>> I started to rely on c-or-c++-ts-mode because there is no other replacement
>>>> to use for such mappings in init files:
>>>>   (when (and (treesit-ready-p 'c t) (treesit-ready-p 'cpp t))
>>>>     (add-to-list 'major-mode-remap-alist '(c-or-c++-mode . c-or-c++-ts-mode)))
>>>> c-or-c++-mode is activated for all .h files, so there should be the
>>>> corresponding
>>>> c-or-c++-ts-mode, but it's lost somewhere in emacs-29.
>>> 
>>> Apparently it was decided that it's a new feature, and thus too late
>>> for emacs-29.
>> 
>> I added it back. It really is a bug preventing one to use c(++)-ts-mode
>> on header files. So this should be fine to add. Plus I mostly just
>> copy-pasted from cc-mode. Sorry for the back-and-forth.
> 
> Yuan, something is still amiss here: there's a difference in the
> decision whether C or C++ mode should be used between c-or-c++-mode
> and c-or-c++-ts-mode.  For example, visit the file
> dwarf2/line-header.h file from the recent GDB tree: c-or-c++-mode
> decides (correctly) that it's C++, but c-or-c++-ts-mode decides that
> it's C.
> 
> In general, try header files from GDB: GDB is written in C++, but many
> *.h files kept their original *.h names, so you have a lot of testing
> cases there.  I see quite a few of them where c-or-c++-ts-mode decides
> incorrectly for some reason.
> 
> Thanks.

Weird, I literally copied c-or-c++-mode. Let me see what’s going on.

Yuan



bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 18 Feb 2023 12:24:11 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 39 days ago.

Previous Next


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