[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 19:10:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 17/01/2023 19:02, Eli Zaretskii wrote:
Date: Tue, 17 Jan 2023 17:22:05 +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 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)

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

Why not?  It's easy and quick and solves all the problems you
mentioned (and then some).

That would increase the time and effort required for such an investigation ~5x. (*)

> Like I said: I'm using this myself all the
> time.

I'm reasonably certain that, for the tasks that I do, my workflows are better optimized.

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.

No need for paper: just M-w the data and yank into your production
session (which stays up and running all the time).  Again, I'm doing
this all the time in my work on Emacs.

Likewise (*), but with a smaller multiplier.

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

You can start from "emacs -Q" and load whatever is needed.  You can
make an ad-hoc init file that loads everything you need automatically,
to save manual typing.  I'm doing this all the time when the setup is

And now more people will have to, in less complicated situations, which previously required no such preparation.

reply via email to

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