Re: Turning on/off tree-sitter modes

[Dmitry Gutov]

On 30/11/2024 20:49, Stefan Monnier wrote:
> > > In any case I was thinking of a UI that's not specific to tree-sitter
> > > that works as follows:
> > >      (defun change-major-mode (newmode)
> > >        (interactive (list (read-the-new-mode)))
> > >        (cond
> > >         ((eq major-mode (the-mode-normally-selected-by-auto-mode-alist))
> > >          (setf (alist-get major-mode major-mode-remap-alist) newmode)
> > >          (when (called-interactively-p)
> > >            (customize-mark-as-set 'major-mode-remap-alist)))
> > >         (t
> > >          (let ((regexp (guess-regexp buffer-file-name)))
> > >            (add-to-list 'auto-mode-alist (cons regexp newmode))
> > >            (when (called-interactively-p)
> > >              ...somehow convince Custom to do the above `add-to-list`...))))
> > >        (funcall newmode))
> >
> > That sounds interesting, especially the 'guess-regexp' part. I think
> > it would make it ineligible for calling from the init script, though,
> > which could be a preference for many.
>
> It's definitely meant for interactive use, yes.

Sounds good.

> For the init file, we have things like
>
>      (add-to-list 'major-mode-remap-alist '(foo-mode . bar-mode))
>
> so I don't see any need for anything new.

We might need to solve this for go-ts-mode and etc having no "original" 
to remap from, though. Maybe just using your FIXME (adding 
auto-mode-alist entry for 'go-mode').

> > > `read-the-new-mode` could use a variable like Dmitry's
> > > `treesit--mode-associations` to provide good defaults.
> > > BTW, this var shouldn't be set like in his patch, IMO but via
> > >       ###;;;autoload
> > >       (add-to-list 'treesit--mode-associations (javascript-mode . js-ts-mode))
> >
> > TBF one of my goals for the later patches was to avoid adding new public
> > "registry" variables, like treesit-auto-mode-alist,
> > treesit-major-mode-remap-alist, treesit-interpreter-mode-alist, etc. It
>
> In my mind, `treesit--mode-associations` is just a helper variable for
> the UI, to let modes register themselves as a possible good choice for
> specific languages, so the UI can provide nice defaults and/or completion.
> It should not change the behavior of Emacs in any significant way.

> > >     and its name should not be treesitter-specific either, then.
> > ...But perhaps you have a more general purpose in mind for them.
>
> cperl-mode/perl-mode, latex-mode/LaTeX-mode, c-mode/sm-c-mode,
> caml-mode/tuareg-mode, ...

So like major-mode-remap-alternatives?

If the goal were just to "tag" major mode name symbols, we could 
delegate that to define-derived-mode and 
loaddefs-generate--make-autoload. But that couldn't mention the "from" 
modes, I guess.

> > > We could also have a command `treesit-enable-all-modes` which uses
> > > a variable `treesit-mode-grammars` (an alist mapping modes to grammars,
> > > setup via the same kind of autoload+add-to-list as above), to add to
> > > `major-mode-remap-alist` all the TS modes for which the user has
> > > installed the corresponding grammar.
> > It seemed to me that users might first choose the modes/languages they want,
> > and then be told (sometimes with warnings) which grammars are still missing
> > or cannot be found by Emacs somehow. But there can be different ways of
> > looking at it.
>
> I'd imagine `treesit-enable-all-modes` could emit a warning about
> modes lacking a grammar when used interactively, and offer (maybe with
> a C-u prefix) to install the grammars?

Sounds reasonable. I was thinking it would be more economical to defer 
the checking of grammars until a mode is actually used (so you can 
enable them all wholesale, and then gradually install needed grammars), 
but that's not critical. Pros and cons either way.

Also, there as a request to exclude some modes from the "enable all" 
action, too. I took that to mean that we need a user option.