From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: casouri@gmail.com, monnier@iro.umontreal.ca, larsi@gnus.org,
theo@thornhill.no, jostein@secure.kjonigsen.net,
emacs-devel@gnu.org
Subject: Re: Make all tree-sitter modes optional
Date: Tue, 17 Jan 2023 17:22:05 +0200 [thread overview]
Message-ID: <0380a032-bca0-4225-6f9d-853de49f100f@yandex.ru> (raw)
In-Reply-To: <83pmbd2oy6.fsf@gnu.org>
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.
next prev parent reply other threads:[~2023-01-17 15:22 UTC|newest]
Thread overview: 119+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <84973.1672843723@hassadar.pretzelnet.org>
[not found] ` <83wn62xi3k.fsf@gnu.org>
[not found] ` <m1cz7u5brr.fsf@yahoo.es>
[not found] ` <83o7rexe2n.fsf@gnu.org>
[not found] ` <83h6x5xym7.fsf@gnu.org>
2023-01-15 14:01 ` Make all tree-sitter modes optional Eli Zaretskii
2023-01-15 23:39 ` Dmitry Gutov
2023-01-16 7:43 ` Theodor Thornhill
2023-01-16 16:30 ` Dmitry Gutov
2023-01-16 12:34 ` Eli Zaretskii
2023-01-16 13:06 ` Dmitry Gutov
2023-01-16 14:20 ` Eli Zaretskii
2023-01-16 14:50 ` Dmitry Gutov
2023-01-16 14:59 ` Eli Zaretskii
2023-01-17 12:59 ` Dmitry Gutov
2023-01-17 13:47 ` Eli Zaretskii
2023-01-17 14:32 ` Dmitry Gutov
2023-01-17 14:52 ` Eli Zaretskii
2023-01-17 15:22 ` Dmitry Gutov [this message]
2023-01-17 17:02 ` Eli Zaretskii
2023-01-17 17:10 ` Dmitry Gutov
2023-01-17 17:38 ` Eli Zaretskii
2023-01-17 17:59 ` Dmitry Gutov
2023-01-17 18:04 ` Eli Zaretskii
2023-01-17 18:21 ` Dmitry Gutov
2023-01-17 18:40 ` Eli Zaretskii
2023-01-17 18:49 ` Dmitry Gutov
2023-01-17 19:03 ` Eli Zaretskii
2023-01-17 19:21 ` Dmitry Gutov
2023-01-18 1:11 ` Yuan Fu
2023-01-18 1:23 ` Dmitry Gutov
2023-01-18 3:34 ` Eli Zaretskii
2023-01-18 3:52 ` Dmitry Gutov
2023-01-18 12:06 ` Eli Zaretskii
2023-01-18 14:00 ` Dmitry Gutov
2023-01-18 14:51 ` Eli Zaretskii
2023-01-18 12:36 ` Stefan Monnier
2023-01-17 17:34 ` treesit-forward-sexp (was: Make all tree-sitter modes optional) Juri Linkov
2023-01-17 17:40 ` Theodor Thornhill
2023-01-17 18:17 ` treesit-forward-sexp Juri Linkov
2023-01-17 17:50 ` treesit-forward-sexp (was: Make all tree-sitter modes optional) Dmitry Gutov
2023-01-17 17:59 ` Eli Zaretskii
2023-01-16 1:12 ` Make all tree-sitter modes optional Po Lu
2023-01-17 17:30 ` Juri Linkov
2023-01-17 17:58 ` Eli Zaretskii
2023-01-17 18:19 ` Juri Linkov
2023-01-17 18:41 ` Eli Zaretskii
2023-02-14 19:08 ` Alan Mackenzie
2023-02-14 19:29 ` Eli Zaretskii
2023-02-14 21:02 ` Alan Mackenzie
2023-02-15 15:35 ` Eli Zaretskii
2023-02-15 17:57 ` Alan Mackenzie
2023-02-15 18:33 ` Eli Zaretskii
2023-02-15 20:31 ` Alan Mackenzie
2023-02-16 5:41 ` tomas
2023-02-16 7:27 ` Eli Zaretskii
2023-02-16 22:05 ` Yuan Fu
[not found] ` <87v8k2g04m.fsf@dick>
2023-02-15 20:34 ` Eli Zaretskii
[not found] ` <87mt5eegkw.fsf@dick>
2023-02-16 7:53 ` Eli Zaretskii
2023-02-16 8:52 ` Po Lu
2023-02-15 21:40 ` Alan Mackenzie
2023-02-17 13:30 ` Alan Mackenzie
2023-02-17 13:37 ` Po Lu
2023-02-17 13:46 ` Stefan Monnier
2023-02-17 14:16 ` Po Lu
2023-02-17 14:40 ` Eli Zaretskii
2023-02-17 14:56 ` Dmitry Gutov
2023-02-17 15:04 ` Eli Zaretskii
[not found] ` <8735741fic.fsf@dick>
2023-02-17 15:41 ` Alan Mackenzie
2023-02-17 16:04 ` Make all tree-sitter modes optional Stefan Kangas
2023-02-17 17:42 ` Morgan Willcock
2023-02-17 15:15 ` Gregory Heytings
2023-02-17 13:54 ` Alan Mackenzie
[not found] ` <d4c1a7f6-b5bf-f4f3-8d79-1c6b1d07cf70@yandex.ru>
2023-02-17 14:22 ` Po Lu
2023-02-17 14:58 ` Eli Zaretskii
2023-02-17 15:18 ` Alan Mackenzie
2023-02-15 18:34 ` Stefan Monnier
2023-02-15 19:01 ` Dmitry Gutov
2023-02-15 19:26 ` Stefan Monnier
2023-02-15 19:47 ` Eli Zaretskii
2023-02-15 19:53 ` Stefan Monnier
2023-02-15 20:06 ` Eli Zaretskii
2023-02-15 21:04 ` Stefan Monnier
2023-02-16 7:42 ` Eli Zaretskii
2023-02-16 9:49 ` Basil L. Contovounesios
2023-02-16 11:48 ` Eli Zaretskii
2023-02-16 14:41 ` Stefan Monnier
2023-02-16 15:42 ` Eli Zaretskii
2023-02-16 16:45 ` Stefan Monnier
2023-02-16 17:05 ` Eli Zaretskii
2023-02-16 19:14 ` Dmitry Gutov
2023-02-16 20:07 ` Stefan Monnier
2023-02-16 5:45 ` tomas
2023-02-16 8:26 ` Eli Zaretskii
2023-02-16 10:30 ` Alan Mackenzie
2023-02-16 12:38 ` Po Lu
2023-02-16 12:53 ` Dmitry Gutov
2023-02-15 20:24 ` Dmitry Gutov
2023-02-16 7:05 ` Eli Zaretskii
2023-02-16 7:53 ` Theodor Thornhill
2023-02-16 8:34 ` Eli Zaretskii
2023-02-16 8:46 ` Theodor Thornhill
2023-02-16 11:58 ` Dmitry Gutov
2023-02-16 11:56 ` Dmitry Gutov
2023-02-16 14:48 ` Theodor Thornhill via Emacs development discussions.
2023-02-16 14:56 ` Dmitry Gutov
2023-02-16 15:15 ` Theodor Thornhill
2023-02-15 23:48 ` Lynn Winebarger
2023-02-16 2:56 ` Stefan Monnier
2023-02-15 19:07 ` Eli Zaretskii
2023-02-15 19:27 ` Stefan Monnier
2023-02-15 21:06 ` Basil L. Contovounesios
2023-02-16 7:44 ` Eli Zaretskii
2023-02-15 18:25 ` Juri Linkov
2023-01-19 16:53 Pedro Andres Aranda Gutierrez
2023-01-20 8:30 ` Eli Zaretskii
2023-01-20 16:31 ` Pedro Andres Aranda Gutierrez
2023-01-20 19:13 ` Eli Zaretskii
2023-01-21 11:30 ` Pedro Andres Aranda Gutierrez
2023-01-21 11:48 ` Eli Zaretskii
2023-01-22 6:23 ` Pedro Andres Aranda Gutierrez
2023-01-22 6:38 ` Eli Zaretskii
2023-01-22 10:46 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2023-02-18 7:55 Pedro Andres Aranda Gutierrez
2023-03-11 12:45 ` Ongaro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0380a032-bca0-4225-6f9d-853de49f100f@yandex.ru \
--to=dgutov@yandex.ru \
--cc=casouri@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=jostein@secure.kjonigsen.net \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).