From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Make all tree-sitter modes optional Date: Tue, 17 Jan 2023 16:52:33 +0200 Message-ID: <83pmbd2oy6.fsf@gnu.org> References: <84973.1672843723@hassadar.pretzelnet.org> <83wn62xi3k.fsf@gnu.org> <83o7rexe2n.fsf@gnu.org> <83h6x5xym7.fsf@gnu.org> <83h6wr6gmz.fsf@gnu.org> <831qnu64la.fsf@gnu.org> <83o7qy4l2v.fsf@gnu.org> <55d39dcb-de2f-fe02-e069-f1dd1e50e59b@yandex.ru> <83edru4jaj.fsf@gnu.org> <83sfg92ryn.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13041"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, monnier@iro.umontreal.ca, larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 17 15:53:22 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pHnKz-0003FX-Ib for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Jan 2023 15:53:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHnKC-0002XH-3w; Tue, 17 Jan 2023 09:52:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHnK6-0002WM-2h for emacs-devel@gnu.org; Tue, 17 Jan 2023 09:52:27 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHnK4-0007EO-Oi; Tue, 17 Jan 2023 09:52:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=J7s+xziRzh2pJ6NtVTctGs4Sg4fG4p3ZKPnCdW9upns=; b=LbGU2VPje4IW X0vAWsA8RUs4onrPtX6sEoGb+s9fY+JQ8gCFMcfnhkZBEzIonNT9Ny01DGFyaLzCxuFYymHkdu+OS xb8j6KjeI+gGbWvRWnosznEfXQUyktQRH1imd2C4vLh3HKLuk8i3pgP4Tag15m78bti9eUtgA38aK Gy731zQWL96Ce6qcYz8Vjr/9uZfd6OGNqZMZWGYuiu76XcHEYy49lVzHOQIKmR/YLJvNQKd9GK+jv qemiyy8YDSUsxJmu0FHNLfgffNY0jSpC0sXphEN2Ak7gQB3VUcWLGoqj5TrWarCsOSfTnFVOYS/RE L7vW9WKd5fZytZnixS63mQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHnK2-0006L9-Js; Tue, 17 Jan 2023 09:52:24 -0500 In-Reply-To: (message from Dmitry Gutov on Tue, 17 Jan 2023 16:32:30 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302479 Archived-At: > 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 > > 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'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. > 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. > 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. My suggestion to anyone who does such testing is to use separate sessions.