Re: Make all tree-sitter modes optional

[Dmitry Gutov]

On 17/01/2023 15:47, Eli Zaretskii wrote:
> > Date: Tue, 17 Jan 2023 14:59:06 +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>
> >
> > On 16/01/2023 16:59, Eli Zaretskii wrote:
> > > You can file a bug report if you want, but it won't count because it
> > > won't tell anything we don't know already.
> >
> > The fact that it will make it a pain for me to test ruby-ts-mode in
> > "regular" sessions was something you'd been aware of already?
>
> Please tell more details about this aspect of the issue.

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?

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.

But that will only affect scenario 1. The second scenario is fairly 
likely to start with 'emacs -Q' (to try to eliminate the effect of user 
customizations).

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.