emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Turning on/off tree-sitter modes


From: Stefan Monnier
Subject: Re: Turning on/off tree-sitter modes
Date: Sat, 30 Nov 2024 13:49:42 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

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

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.

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

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


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]