Re: Make all tree-sitter modes optional

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 17 Jan 2023 16:32:30 +0200
> Cc: casouri@gmail.com, monnier@iro.umontreal.ca, larsi@gnus.org,
>  theo@thornhill.no, jostein@secure.kjonigsen.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> I'm using ruby-mode, at least for now, while all the wrinkles with 
> indentation haven't been ironed out (and we'll probably not manage to 
> get them all 100% right before the 29 release), and while ts modes don't 
> support show-paren-mode like SMIE does. No proper sexp navigation, etc.
> 
> So here I am, in my normal Emacs, working. Suppose a bug report comes 
> in, I switch to a new buffer (maybe visiting a pre-existing file, maybe 
> not), turn on ruby-ts-mode, reproduce it. Then try to fix it.
> 
>  From that moment on, my current session has a different major mode 
> associated with Ruby files, and I have to deal with that somehow.
> 
> Or a different scenario:
> 
> Recently I had to investigate worse font-lock performance of 
> ruby-ts-mode compared to ruby-mode. How did I test that? I started a new 
> session and visited a bunch of existing files. First I run the benchmark 
> in ruby-mode (which it's associated with by default), then I switch to 
> ruby-ts-mode, repeat the benchmark, compare the results. And I do that 
> for a number of files.
> 
> With your change, the first file will start with ruby-mode, but the 
> second file and the rest will start in ruby-ts-mode. And I would somehow 
> need to remember that change and account for it when evaluating the results.
> 
> What's your recommendation?

My recommendation is to use separate, throw-away Emacs sessions for
any such testing.  I'm doing that myself for a long time, for reasons
unrelated to the issue at hand -- simply because (a) my production
sessions are too customized for clean-room testing, and (b) because my
production sessions are too valuable to me to risk loading non-trivial
packages that change the defaults.

I'm frankly surprised that this is not what you do in your testing.  I
was quite sure that everyone who does any serious development or
maintenance work in Emacs does something like that.  How else is it
possible to, e.g., load some obscure package someone says is necessary
for reproducing a problem?

So in your case, when I'm done with testing whatever I need to test in
ruby-ts-mode, I ether shut down that session, or start another one in
parallel if I need to compare it with, say, ruby-mode.

> I suppose I could add these two forms to the init script:
> 
>    (require 'ruby-ts-mode)
>    (add-to-list 'auto-mode-alist <...huge regexp from ruby-mode.el...>)
> 
> ...and then update it over the years if new entries are added there over 
> the years -- by the way, having a separate regexp in ruby-ts-mode.el is 
> an unfortunate duplication.

If this is about the difference between the regexps, we can fix that,
I don't object to have both modes handle the same files.

> Also try to imagine some prospective ruby-ts-mode contributor who is not 
> one of us, but who's also trying to test and compare the two modes.

My suggestion to anyone who does such testing is to use separate
sessions.