Re: Make all tree-sitter modes optional

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

I missed this thread back in January, due to being away from Emacs
development for a time, and I think the current state of this feature is
so far away from ideal as to make some design and implementation
advisable.

On Tue, Jan 17, 2023 at 19:58:40 +0200, Eli Zaretskii wrote:
> > From: Juri Linkov <juri@linkov.net>
> > Cc: casouri@gmail.com,  monnier@iro.umontreal.ca,  larsi@gnus.org,
> >   theo@thornhill.no,  jostein@secure.kjonigsen.net,  emacs-devel@gnu.org
> > Date: Tue, 17 Jan 2023 19:30:16 +0200

> > It fails for many scenarios:

> > 1. The user needs to use e.g. js-ts-mode.  Your patch requires that
> > users first visit a js file in js-mode, then they need to type

> >   M-x js-ts-mode RET

> > then for the rest of the session they can use js-ts-mode.
> > But for a new session they need to repeat the same again.

> Or customize auto-mode-alist.

> This is a consequence of the fact that js-ts-mode doesn't have a
> separate .el file.  If you have better ideas for that, I'm all ears.

> > 2. For other ts modes adding something like (require 'c-ts-mode)
> > to the user's init file is not a clean way to enable such modes.

> Why not?

> > Also takes additional space even when users don't intend to use them
> > in the current session, thus negating the benefits of autoloading.

> Once again, if the above is somehow too annoying, they can customize
> auto-mode-alist manually.  Or even use use-package (and have full
> benefit of autoloading).  In any case, the fact that a mode is loaded
> and not used is not a problem large enough to reject this simple
> arrangement.  Moreover, if someone puts the require into their init
> file, they probably want to use the mode quite a lot, so it will not
> remain ballast for too long.

> > 3. There is no simple way to disable a ts mode after loading
> > the corresponding ts file.

> Yes, there is: restart the session.  IMO, adequate enough for
> something you want to try, and then find not to like.

No, it is not adequate.  It is horrible.  It forces the user to discard
all the state in his Emacs session, and restart, which is s..l..o..w..,
particularly if said user has a large desktop file.  In my experiments
with c-ts-mode, I switched backwards and forwards several times between C
Mode and c-ts-mode.  This now corrupts my Emacs session, in that C Mode
is no longer the default for C files.  I got caught out this evening when
I opened a C file, and something failed to work on it because it opened
in c-ts-mode.

This seems to be undocumented in NEWS.

I think lots of users are going to hate having the new -ts- modes forced
upon them in this manner.  Normally, when a new feature is introduced
into an Emacs version, it is fully optional, and defaults to disabled.
Why do the -ts- modes not conform to this well established practice?

There appears to be no way, apart from editing the Lisp source files, to
make C Mode the default for .c files when there are also c-ts-mode
buffers in the session.  This is a Bad Thing.

> Bottom line: if you have better, simpler solutions, please tell.

How about commands c-make-ts-default-mode and c-make-ts-undefault-mode
(and analogous functions for the other ts-modes)?  The first of these
would push the new entries onto auto-mode-alist and the second would
remove them again.  Or we could have a customisable option,
c-default-c-mode which users could set when they are ready.  Either of
these would allow the user to try out the new modes freely without being
coerced against their will to use the new -ts- modes.

> The ones you proposed until now are significantly more complex, and it
> is not reasonable to ask users to go to such lengths to try a new mode.

Any reasonable solution is going to be more complicated than the current
code.  I don't think it reasonable silently to force users into setting the
new modes as defaults.  They should be able to try out a new mode simply
by doing M-x c-ts-mode, or the like, then go back to their normal way of
working.

> But of course, if someone wants to do it in a more complex and more
> flexible way, they still can.

-- 
Alan Mackenzie (Nuremberg, Germany).