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

[Eli Zaretskii <eliz@gnu.org>]

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