From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: Turing on tree-sitter Date: Mon, 10 Oct 2022 09:54:49 -0700 Message-ID: <29BCEC0D-8172-4DDB-ABC0-98F58971027A@gmail.com> References: <83czb1jrm3.fsf@gnu.org> <87v8ot2nfi.fsf@posteo.net> <837d19jfia.fsf@gnu.org> <83edvgi3mx.fsf@gnu.org> <87r0zg5g76.fsf@thornhill.no> <78205E8D-B2D4-4460-BE0A-9BF7C627A79B@gmail.com> <87zge4b0lc.fsf@posteo.net> <83zge4gk9z.fsf@gnu.org> <434B99AD-F307-492A-8E9A-27C84CC575B0@gmail.com> <875ygrabpm.fsf@posteo.net> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12230"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Eli Zaretskii , Theodor Thornhill , emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 10 19:09:15 2022 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 1ohwHD-000317-6X for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Oct 2022 19:09:15 +0200 Original-Received: from localhost ([::1]:50948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohwHB-0006zt-An for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Oct 2022 13:09:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47918) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohw3N-0002F5-CV for emacs-devel@gnu.org; Mon, 10 Oct 2022 12:54:57 -0400 Original-Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]:40820) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ohw3L-0006vi-7W; Mon, 10 Oct 2022 12:54:56 -0400 Original-Received: by mail-pj1-x1030.google.com with SMTP id g8-20020a17090a128800b0020c79f987ceso5813933pja.5; Mon, 10 Oct 2022 09:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UK8GsUEaKeDHo2yHNSl/pgpAW81pgUxrgE9fwbGDMPU=; b=Du9Ag7HGY2/gtvHKy5Y3JqYFG3h8uL08DtjjnSCZqIRucqvEGWA2G5107Bkzi1J5tA wu83Df5E9O480BhoTn6VjxHbUX/I6NOAadvaQIXByzmYgo3Kjp+kXgmek2DcETvmp6u0 6lDiPxL8xIUY4LRYdGLlUSBf8JMqDzA7/Gtk8mGTFnDbbsbdguTbpu/ZHUiKaGw/MM7b DFcf7O+CU6pAPhdIVttprl/HZx2W17lFtFAspug6X9+uWFSbpdu9fQL19pv4+PQ2DyUv HaNGRr5wE3Tj0QJ1TZetQZpLm6b+gdF/U3qpUda5L6YOHub1q2V9UGfg0rS3iySurdeN p8tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UK8GsUEaKeDHo2yHNSl/pgpAW81pgUxrgE9fwbGDMPU=; b=x/Efilp6wo668HBO1co+Nq+r4d2OC0peiRA6j3MPsLBN37NBjVYt0aEqIc1jx+i8bD l+g0NEJKU8SjcyptoIFYHeUDLbtK8SvFzHYCTP8cyZHQIF7ePQ+XHZpDIwdFGLPnGkAs 12kp2PrRdNlDlkCU/xA+0Fpl87RCKyAgzNDY6UefYZ3NYFSGqXgdvaU1vPkrAPTPvvR5 /guM5Vq2YXrh0goCUPtj9ffHnY30nJQOvnjHk7AYD5bjbTp4zLfTMKV+HpFKNLpNVgK0 TqRmBM85uPyU5jvSnmnFbtiJ0jAvgFL5WhfF6c5ivQfi14JJw1Kne5FFXPdp1EmFH6z4 eVwA== X-Gm-Message-State: ACrzQf2GcEdCjZ/223fWQ1zPYTZiSEppPGR2EHZJ2YuBZyX+xnrRpLFG NbJFjXE+JRGgeH9qgHcDdnc= X-Google-Smtp-Source: AMsMyM67N9AjmwF86rMp7QdMDwUgCEBQXersVYSDW9s6GyGToQarLdEMEz50WHueGSsQShqpaatzgw== X-Received: by 2002:a17:902:ea0c:b0:181:61d1:ac1c with SMTP id s12-20020a170902ea0c00b0018161d1ac1cmr11622598plg.120.1665420891345; Mon, 10 Oct 2022 09:54:51 -0700 (PDT) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id g12-20020a170902868c00b0017f7f8bb718sm6832733plo.232.2022.10.10.09.54.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Oct 2022 09:54:50 -0700 (PDT) In-Reply-To: <875ygrabpm.fsf@posteo.net> X-Mailer: Apple Mail (2.3696.120.41.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::1030; envelope-from=casouri@gmail.com; helo=mail-pj1-x1030.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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" Xref: news.gmane.io gmane.emacs.devel:297388 Archived-At: > On Oct 10, 2022, at 9:24 AM, Philip Kaludercic = wrote: >=20 > Yuan Fu writes: >=20 >>> On Oct 10, 2022, at 7:52 AM, Stefan Monnier = wrote: >>>=20 >>>>> Is there a reason we can't use a minor mode? Something like >>>>>=20 >>>>> (add-hook 'python-mode-hook #'treesit-mode) >>>>>=20 >>>>> or a list >>>>>=20 >>>>> (add-to-list 'treesit-modes 'python-mode) >>>>>=20 >>>>> ? >>>>=20 >>>> We could, if a minor mode is justified. When this was previously >>>> brought up, someone said the justification for a minor mode was too >>>> weak in most cases. But maybe we should revisit that idea. >>>=20 >>> I think a buffer-local `treesit-mode` plus a `global-treesit-mode` = would >>> make a lot of sense, from a user's perspective. This way they don't >>> have to hunt for the name of the boolean variable that their mode >>> decided to use to control the use of treesitter: all modes use the = same >>> boolean variable called `treesit-mode`. >>=20 >> Usually users set buffer-local variables in a major mode hook, which >> runs after the major mode is loaded, no? But major modes need to know >> whether to use tree-sitter up-front. >=20 > What if the hook is a noop and the mode definition just checks if the > function is a member? Or is there no way to re-fontify a buffer? IMO that=E2=80=99s a bit hacky, we have plenty better options. >=20 >> I don=E2=80=99t think xxx-mode-use-tree-sitter would be hard to find = if every >> mode uses this pattern. Though now we are discussing adding separate >> major modes which wouldn=E2=80=99t use this variable. I think that = indeed >> could be confusing. (How do I know if xxx language uses >> xxx-mode-use-tree-sitter or a separate major mode >> xxx-tree-sitter-mode?) >=20 > I think the issue here is not so much discoverability, but = consistency. > Having to a different option for every mode can get annoying and is > difficult to automate. It is also unnecessarily decentralised. That = is > why I think that having a single list like `treesit-modes' (by = whatever > name) would be nice to have. Using the easy customisation interface > you'd represent it as a set/radio menu where you get a list of = supported > languages you can tick. That=E2=80=99s nice, but it wouldn=E2=80=99t make much sense to add A to = the list when A-mode doesn=E2=80=99t actually support tree-sitter. I = think of tree-sitter as something at major mode level. >=20 >>> Then again, to me a minor mode is something so cheap that the idea = that >>> "justification for a minor mode was too weak" is rather hard to = grasp. >>=20 >> I don=E2=80=99t think there is too much problem using minor modes, = but minor >> modes wouldn=E2=80=99t fit very well with separate major modes. IMO = it would >> be weird if turning on tree-sitter-mode changes the major mode. >=20 > I don't get why a `tree-sitter-mode' should change the major mode? My bad, I thought Theodor was saying he would add separate major modes = alongside non-tree-sitter major modes for the same language. Reading his = message I think he is only adding the tree-sitter powered mode into core = and leaving the non-tree-sitter version out. So IIUC we will have (a) major modes that supports both tree-sitter and = non-tree-sitter, and (b) major modes that require tree-sitter to work. Again, a M-x treesit-enable in a mode that requires tree-sitter to work = doesn=E2=80=99t make much sense. I think having individual major-mode = level toggle variables and a global toggle variable is conceptually more = fit? Yuan=