From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Average-user-facing interface for tree-sitter Date: Mon, 24 Oct 2022 10:14:01 -0700 Message-ID: <867d0pjg9y.fsf@stephe-leake.org> References: <8BAAB6CC-C8BA-4255-9E60-8963A828BE31@gmail.com> Mime-Version: 1.0 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="15206"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Fu Yuan , Theodor Thornhill , Lars Ingebrigtsen , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 24 19:42:18 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 1on1Ss-0003jX-3z for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Oct 2022 19:42:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1on11q-00066c-MT; Mon, 24 Oct 2022 13:14:22 -0400 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 1on11p-00066S-75 for emacs-devel@gnu.org; Mon, 24 Oct 2022 13:14:21 -0400 Original-Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1on11m-0001pl-Hx for emacs-devel@gnu.org; Mon, 24 Oct 2022 13:14:20 -0400 Original-Received: from cmgw10.mail.unifiedlayer.com (unknown [10.0.90.125]) by progateway4.mail.pro1.eigbox.com (Postfix) with ESMTP id 9BFD3100485FD for ; Mon, 24 Oct 2022 17:14:05 +0000 (UTC) Original-Received: from host2007.hostmonster.com ([67.20.76.71]) by cmsmtp with ESMTP id n11ZoSJZGT2g2n11ZoslOf; Mon, 24 Oct 2022 17:14:05 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=Pds6Ogtd c=1 sm=1 tr=0 ts=6356c7dd a=dWLzHQi6WpdymmZIwiVdBw==:117 a=Fln8i1WyhtedwaIJAdHvmw==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=IkcTkHD0fZMA:10:nop_charset_1 a=Qawa6l4ZSaYA:10:nop_rcvd_month_year a=vvvmwbhNdt4A:10:endurance_base64_authed_username_1 a=iRZporoAAAAA:8 a=fnXmsNHUz6PuzdaQmdcA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=NOBgFS-JBQ2l-kSd6-zu:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=stephe-leake.org; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rAxz2ySlGVVFsP0NPWxXBSdNFTc9+/tMRRx4Byc5Y8E=; b=nSN/kLT5FvLllzP5h2WTV61kfV W8C/60Fr7E59erEO6OqyLBOlG2Od5Qx05vzmWIHLqWntPv9oKot6Qv4fplKlIP80ccr3Wfh4gatyV SfM8f+MURsIf3t1maaFrnxH5dbBfmsSJdPa+CUpgb/QITRsyFooMaE6c9cQgvXuJp9/Mb6KK4NqKQ iGIwVFYwpwMw2qYdM1xZyYnO0B2odEKGG4pLK/qOCF0PRFxWeuVyCWqacoJAgJxR5/rRrjaOOp9Wj 7HWiAQIjwsO+Wek4+glkyhM70GUBWxgH7zygQrBEduBOUP2BwAn0xvmqoZr02Nm/U5kgqiz9kA7X7 kP0LbNIg==; Original-Received: from 135-180-197-170.fiber.dynamic.sonic.net ([135.180.197.170]:53719 helo=DESKTOP-G20DCG1) by host2007.hostmonster.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1on11Y-002YLi-Q3; Mon, 24 Oct 2022 11:14:04 -0600 In-Reply-To: (Stefan Monnier's message of "Mon, 24 Oct 2022 08:57:02 -0400") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host2007.hostmonster.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - stephe-leake.org X-BWhitelist: no X-Source-IP: 135.180.197.170 X-Source-L: No X-Exim-ID: 1on11Y-002YLi-Q3 X-Source-Sender: 135-180-197-170.fiber.dynamic.sonic.net (DESKTOP-G20DCG1) [135.180.197.170]:53719 X-Source-Auth: stephen_leake@stephe-leake.org X-Email-Count: 5 X-Source-Cap: c3RlcGhlbGU7c3RlcGhlbGU7aG9zdDIwMDcuaG9zdG1vbnN0ZXIuY29t X-Local-Domain: yes Received-SPF: pass client-ip=69.89.18.3; envelope-from=stephen_leake@stephe-leake.org; helo=gproxy2-pub.mail.unifiedlayer.com X-Spam_score_int: 16 X-Spam_score: 1.6 X-Spam_bar: + X-Spam_report: (1.6 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SBL_CSS=3.335, 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: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298400 Archived-At: Stefan Monnier writes: >> Here=E2=80=99s my thought (that didn=E2=80=99t go anywhere): since major= modes sets >> a plethora of local hooks and variables, only the major mode itself knows >> how to reverse them. The cleanest way is probably to clear all the local >> variables and hooks and re-run the major mode setup, which suggests we >> should let major mode branch on whether to enable tree-sitter during >> initialization. I wonder if minor modes can somehow work with this model? > > Re-running is fairly problematic. Not only because it risks repeating > side effects but also because it starts by killing all buffer-local > vars, so we'd need extra hacks to try and preserve the treesit-mode's > own information (making it permanent-local is one way, but that can > cause further breakage when the user really wants to change to another > mode, so it tends to be hackish). > >> It would be also nice to leave room for inclusion of other =E2=80=9Cback= ends=E2=80=9D >> besides elisp and tree-sitter in the future. > > I'm not comfortable with this notion of "backend", because each one of > those "backends" (elisp, treesit, eglot, ...) tends to support > a different set of features, so in practice, I'd expect that in the > common case many major modes will use a mix of those backends. Yes, one backend choice for each feature (most backends will provide more than one feature). There cannot be two backends for indent, but there can be different backends for indent and face. > A simple solution, tho not as elegant as I'd like, is to keep the code > we have (where the major mode sets all vars upfront) but add to the > major mode something like: > > (add-hook 'treesit-mode-hook #'js--treesit-mode-hook nil t) > (js--treesit-mode-hook) > > where `js--treesit-mode-hook` is in charge of removing those settings > that don't apply when `treesit-mode` is enabled` (and to re-instate > them when `treesit-mode` is disabled, which is why I call it right away > in the example above, so we don't duplicate the code between the major > mode's body and the `js--treesit-mode-hook`). Since js--treesit-mode-hook is provided by the major-mode, how is that better than simply including that code in js-mode, in a cond or cl-ecase on the desired backend for each feature? Ah; js--treesit-mode-hook (I object to the name; it's _not_ a hook variable! It might as well be js-treesit-minor-mode) also does unset. But what calls it to do the unset? I don't see the need for that, except possibly when the user is still experimenting to determine which backend is best. In that case, I always prefer restarting Emacs; that's the only way to ensure the previous mode is fully unset (ie, not even loaded). I set the backend choices in my .emacs, and change them rarely (next time I change one will be when ada_language_server gains SemanticToken support, allowing face via eglot). I suppose there could be a situation where one xref backend is good at one task (say finding references in system libraries), while another is good at something else (maybe finding all refs withing one file); then you might want to swap backends on the fly. The wisi and ada_language_server xref facilities may actually be like that; I need to experiment some more. Or this could argue for splitting the xref feature in two, for global and local xref. It will take some experience to settle on a good common set of features. Another place where the backend matters; refactoring. For example wisi and ada_language_server offer disjoint refactoring operations, all useful. So to allow using all of them in ada-mode, each refactoring function will use whichever backend provides that function; there will be no ada-refactoring-backend setting. > We could try and help write this code by providing a helper function > that relies on some buffer-local var containing a list of vars to be set > (along with their values), a list of hooks to add (and remove), ... > so we don't need to duplicate the list into a "set" and an "unset" > branch like I had to do in the patch. That would be good. > Note that it's very similar to a "backend" function. But it's only > meant to choose between "treesit activated" and "treesit not > activated". We should also allow for eglot, wisi, and other future backends. --=20 -- Stephe