Re: Make all tree-sitter modes optional

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Wed, Feb 15, 2023 at 20:33:49 +0200, Eli Zaretskii wrote:
> > 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.

I wouldn't.  If I type M-x foo-mode in a buffer, I would be surprised if
something changed that without asking me.

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

Possibly.  But we're looking for something simple and reliable at the
moment.  Adding code to check for the presence of c-mode in
auto-mode-alist would add some complexity, and may not really be needed.

> > > > > 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 think we can do things about it, hence my patch from yesterday evening
and this discussion.

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

Because it's unexpected to the users, something which throws them out of
their rhythm, and forces them to expend time and energy getting back to
where they wanted to be.  Not all users, but likely enough of them to
matter.

[ .... ]

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

Again, we differ here.  You're picturing a process where a user one day
makes a definitive decision to switch, and does so permanently.  Maybe
that's how you work, it's not how I work.  I would find myself with a
spare few minutes, experiment a bit with the new mode, then carry on with
my work, maybe experiment a bit more.  I would subconsciously expect my
Emacs state would not be changed by such experimentation.  But it is, in
a way which is difficult to reverse.  Again, I don't understand why
you're content that such difficulty remain.

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

Probably most users start Emacs in the morning and shut it down in the
evening.  I certainly do.  I think a user who gets into this problem is
going to have to spend, perhaps, between 1 and 2 hours getting it sorted
out, or on the other hand, will continue dissatisfied at having to type
M-x c-mode after loading each and every C file.  Why do you not see this
as a bad thing?

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

NEWS has always introduced new features, and amongst the description is
(almost) always some text telling users how to restore the old behaviour.
Why do we not do that here?

> > > 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 thought
> everybody who is involved in Emacs maintenance does that.

Everybody uses Emacs differently.  Even (especially) amongst Emacs
developers.

-- 
Alan Mackenzie (Nuremberg, Germany).