Re: Make all tree-sitter modes optional

[Eli Zaretskii]

> Date: Wed, 15 Feb 2023 17:57:15 +0000
> Cc: juri@linkov.net, casouri@gmail.com, monnier@iro.umontreal.ca,
>   larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > So you revert auto-mode-alist to its original shape, but leave the
> > buffers already under c-ts-mode in that mode?  Is that what the users
> > would expect, you think?
> 
> I think so, yes.  The scenario I am envisaging is the user tentatively
> trying c-ts-mode on one, or a few buffers, then doing C-x C-f foo.c to
> carry on with her work using C Mode.

And when going back, they don't want their C/C++ buffers revert to C
mode?  I'd be surprised.

> > Also, this won't work if the user customized auto-mode-alist in some
> > way wrt some of those file-name extensions.
> 
> OK.  How about something like the following instead (untested)?
> 
> (defun c-make-ts-undefault-mode ()
>   "<Doc string>"
>   (interactive)
>   (let (c)
>     (while (setq c (rassq 'c-ts-mode auto-mode-alist))
>       (setq auto-mode-alist (remq c auto-mode-alist)))))

Shouldn't you add the elements of C mode back, in case they were
removed?

> > > > Then they [proposed amendments] aren't "reasonable" at this time.
> > > > Maybe later, maybe on master.
> 
> > > That will be too late, the damage will have been done.
> 
> > What "damage"? why do you call "damage" changes made by others in
> > Emacs as part of Emacs development?
> 
> The damage I'm talking about is the disruption in users' work flow which
> is likely to occur.  Being perfectly blunt, c-ts-mode is not yet as
> capable as CC Mode in some areas, and in any case its configuration is
> wholly different (for good reasons).  Converting to the use of c-ts-mode
> is a project, not something which can just happen.  The current code is
> likely to confuse and anger users when, after trying out c-ts-mode, it
> gradually dawns on them that the reason C Mode no longer works is that
> their newly opened files aren't in C Mode at all.  That is what has
> happened to me several times.

This can happen with any new feature.  There's nothing we can do about
this, so please just stop worrying about it.

> I'm not calling others' changes damage.  I'm calling the disruptive
> effect on users' work flow damage.  That disruption, once it's happened,
> cannot ever be undone.

With the implied assumption that the effect will necessarily be
"disruptive" in many cases.  Why assume that?

> I'm doing my best to help.

Actually, no, you aren't.  "Help" would be to actively partake in the
development of c/c++-ts-mode.  You are our best expert on supporting
these languages, so who better than you to do at least part of this
job, if not coordinate and guide the few brave souls who are motivated
enough to do that in record time.  I'm extremely disappointed that you
completely removed yourself from that effort.  I think we could have
ended up with much better ts modes if you took part in that these last
weeks.

Instead, you only speak up to describe the "disadvantages" of these
new modes, and suggest ways to turn them off.

> > Well, that's exactly why these new modes are entirely optional.
> 
> They're not entirely optional, that's the whole point of my posts over
> the last couple of days.  One can opt in to using c-ts-mode, but opting
> out again is unreasonably difficult.

That's an unusual way of interpreting "opt out".  One doesn't need to
"opt out" of an optional behavior; instead, one should avoid turning
it on, and that's all!

> Even restarting Emacs (which to me is a drastic operation) won't opt
> out if there are still buffers in c-ts-mode in the desktop.

Many people restart Emacs all the time.  And those who use desktop
know how to overcome such problems, which aren't unique to these
modes.

> I don't think the current NEWS item makes this clear enough.

The current NEWS already goes way beyond its purpose and scope in
presenting these new modes and the related issues.  And I object to
using NEWS to tell users in too much detail how NOT to use our new
features: that is like shooting ourselves in the foot.

> > For you and me as users, having to restart Emacs, or having to use a
> > separate session for such experiments, is an entirely reasonable and
> > simple alternative, ....
> 
> Having to restart Emacs is NOT at all reasonable for me, even if it may
> be for you.  Neither is having to use a separate session.  We all use
> Emacs differently, with different expectations.
> 
> > .... one which should eliminate any need for undoing the "damage" of
> > c-ts-mode.
> 
> As I noted above, such restarting will not clear the state of c-ts-mode
> being default whilst there are still c-ts-mode buffers in the desktop.
> Anyhow, there is no mention of using a separate session in NEWS, and
> restarting Emacs is incompletely documented (as already noted).

Sounds like you run your full customized production environment in
test runs of Emacs.  The prudent thing to do is instead to either use
"emacs -Q" or to have a special user/home directory which you use for
such jobs.  Then restarting and/or deleting the desktop is not an
issue at all.  I'm surprised I need to explain that, I though
everybody who is involved in Emacs maintenance does that.