From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Make all tree-sitter modes optional Date: Tue, 17 Jan 2023 17:22:05 +0200 Message-ID: <0380a032-bca0-4225-6f9d-853de49f100f@yandex.ru> 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> <83pmbd2oy6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8335"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: casouri@gmail.com, monnier@iro.umontreal.ca, larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 17 16:23:01 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 1pHnnh-0001wb-Df for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Jan 2023 16:23:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHnmx-0007u0-91; Tue, 17 Jan 2023 10:22:15 -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 1pHnmv-0007sa-4u for emacs-devel@gnu.org; Tue, 17 Jan 2023 10:22:13 -0500 Original-Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pHnmt-0003dp-2J; Tue, 17 Jan 2023 10:22:12 -0500 Original-Received: by mail-ej1-x630.google.com with SMTP id az20so57051210ejc.1; Tue, 17 Jan 2023 07:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=FepIxBWfmRyypxT/Fnu1zj280YI/2XTgdEFY/r+0BO8=; b=RXXs28EZMJpITRyd+yT8ZWpQx0hCoC3lv8hOm9+B4P/GGca7ptIMrT/8eYPVXQuE4t 5Y7RpZwTOyptIBav3RWRvbZjwjaYe8AZXdyd5VXwe/tiPo7VgeAqEEiPlOViejCkPnJ7 DhGtG4moolCPlqF5a0NDqZVgsQlUsRWhZvFxzyWwNK+zgcODKz8kl5NPFwteM6BQZnv6 WLwB+XKCLx+TIYA3GUuiyZnH2HEyqSTYwckn0hnfhfOlHogJvi8VoiIGnSiNiXlDcIBj aOL0AI3QFHT5TFoEj+xkPawGYL3URvZfBE2scQ7PChS4aVl5tJUQrtM8ZXZty/4OKYtu A0Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FepIxBWfmRyypxT/Fnu1zj280YI/2XTgdEFY/r+0BO8=; b=wjS13hLAjloIuw559Sm7NoOsBGUOBSisY49Pl9evIzpF85ZPG4kmoURXZYfdZzwPzQ 0M10iL1mqgKmy0Xlm9M+fpM2IsfipOlEk++0S7a6mBnpLmJKJJnWuki8+j1NookbEEC/ mNUMgVLN4SX541HCAxykb3VV7xMDVgGTwyx5T7/0ROtjUBLRsQvnq5/oJmKFvRFh7dpj oy4ua9TL/VMzgIhlrSNd9SGsOXcd02AM5UeJLwAqHyGbiecEw4EELOIzLKnAj/46aCwb Nf4mhD2JZ6ausSGN+3XhryHqgb2mC/rNIpHD0UHCRyRGFhJJsPyZCH5D+WdsuyTzKO9N jUUA== X-Gm-Message-State: AFqh2koc4cQmXofIUkC7mBWsoHCFbWODLaAi3ix4ep6FGVv6+pst5scM XaXWsDAhV0fYrhYcFKBFptK8MYcoYBs= X-Google-Smtp-Source: AMrXdXsvgm+tf6+UtTRn0RbC+rThyQgjJMCDEh8a9Jis2s0I2iVIYyU9EbE4w7kwkCpQg9bEUt1JYA== X-Received: by 2002:a17:906:698:b0:861:9b5b:4c3b with SMTP id u24-20020a170906069800b008619b5b4c3bmr17207216ejb.17.1673968928983; Tue, 17 Jan 2023 07:22:08 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id og5-20020a1709071dc500b0084d420503a3sm11624203ejc.178.2023.01.17.07.22.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Jan 2023 07:22:08 -0800 (PST) Content-Language: en-US In-Reply-To: <83pmbd2oy6.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::630; envelope-from=raaahh@gmail.com; helo=mail-ej1-x630.google.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.097, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:302480 Archived-At: 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 >> >> 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.