Re: Make all tree-sitter modes optional

[Dmitry Gutov]

On 17/01/2023 16:52, Eli Zaretskii wrote:
> > 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 just mentioned in the previous message that scenario 2 is likely to 
start with 'emacs -Q'.

That doesn't solve the described problem in that scenario.

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

That's untenable.

Running a benchmark is evaluating a form like

  (benchmark-run 1000 (progn (font-lock-mode -1) (font-lock-mode 1) 
(font-lock-ensure)))

I can start a new session for an investigation, but I'm not going to 
restart Emacs every time I evaluate a form.

Doing the benchmarks in a different order (e.g. go through the files 
with one mode and then restart and go with another) is also only an 
option if I were to note the numbers on e.g. a piece of paper. I rarely 
do that; that would also slow me down compared to the current practice.

And also speaking of using 'emacs -Q', that's well-suited to testing 
some classes of bugs, and not so much for others.

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

A common constant would help, with that particular aspect.