bug#60888: 29.0.60; Lost c-or-c++-ts-mode

[Yuan Fu <casouri@gmail.com>]

> On Jan 20, 2023, at 12:38 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Cc: 60888@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Thu, 19 Jan 2023 13:57:17 -0800
>> 
>> 
>> Dmitry Gutov <dgutov@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