[Top][All Lists]

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

Re: Make all tree-sitter modes optional

From: Dmitry Gutov
Subject: Re: Make all tree-sitter modes optional
Date: Tue, 17 Jan 2023 17:22:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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.

reply via email to

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