bug#60176: 29.0.60; Fallback file variable mode if treesitter is not usable

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  sadiq@sadiqpk.org,
>   60176@debbugs.gnu.org
> Date: Tue, 10 Jan 2023 20:08:15 +0200
> 
> >>     (setq (alist-get 'c-mode major-mode-remap-alist)
> >>           (lambda () (if (treesit-available-p) (c-ts-mode) (c-mode))))
> >
> > I don't want to do this by default, because we want users of Emacs 29
> > to turn on TS modes manually, if and when they want that and think
> > they are ready.
> >
> > Of course, I don't mind if the above is done in local customizations
> > by users who are willing to use TS modes whenever they become
> > available.
> 
> Shouldn't we help users by simplifying such complex customization

What is so complex in activating a mode with a single command or a
function call?  Users do that all the time in their init files and
manually.

> and provide a customizable list of modes where tree-sitter is enabled,
> e.g.
> 
> (defcustom treesit-enable-modes nil
>   :type '(repeat
>           (choice (function-item c-ts-mode)
>                   (function-item c++-ts-mode)
>                   (function-item c-or-c++-ts-mode)
>                   ...

I disagree that asking users to customize lists of modes is helping
them.  I think just activating the modes they want, either manually or
in the init files, is a much simpler way of customization.  I don't
understand why you think the above is helping the users in any way.

>              ('c-ts-mode
>               (when (treesit-ready-p 'c t)
>                 (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))))

And this bit is completely unacceptable, from where I stand: it
basically means that the user activated a certain major mode he/she
wanted to use, but the result could be that an entirely different mode
was silently activated instead.  What kind of UX is that, and for a
shining new feature at that??