From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Average-user-facing interface for tree-sitter Date: Mon, 24 Oct 2022 17:07:15 -0400 Message-ID: References: <8BAAB6CC-C8BA-4255-9E60-8963A828BE31@gmail.com> <867d0pjg9y.fsf@stephe-leake.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40775"; 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: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 24 23:34:03 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 1on559-000AIZ-HD for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Oct 2022 23:34:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1on4fN-0004Wy-Nt; Mon, 24 Oct 2022 17:07:25 -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 1on4fM-0004Wq-NH for emacs-devel@gnu.org; Mon, 24 Oct 2022 17:07:24 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1on4fK-0003OU-OX for emacs-devel@gnu.org; Mon, 24 Oct 2022 17:07:24 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E682F441F80; Mon, 24 Oct 2022 17:07:20 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1D6A7441BF8; Mon, 24 Oct 2022 17:07:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1666645639; bh=CpKeB2rPznR/v3RgLBQmS6HLJ9E5X6dcGdDHS7y4hJ4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bzrUaYERnxlLXxwCUidkLo7ZLLVv80hY1g0t282ZyrCpZe9OphoGvw1rvufdyedRk OO2P6HXX8X7DmBaglEfFMNZArV158rBYzdatFhqIjOMQUw0LxFdc8/ljGcxW9rzDBR QFtPL8jUXKJqWA+WQNGLh61z8b4KyzZJ2v0I9n8Ox6TSAYreBn9NJuHeln0+Z9XVrZ N5prTKF3BU6EkJJE99BvqDyufkeOLGVhCX+C9A+LJRHPIaBK7TJ4UK8LBbQZbK9vDd 9gzDbsu7bnqMz5wpZPjSOZWFB9P6MAxnJHSCuqUWGVITc2xiRKc3p5yDRCS0unyZJ4 fu8JhsDip0qLQ== Original-Received: from alfajor (modemcable219.124-130-66.mc.videotron.ca [66.130.124.219]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F2F2A120516; Mon, 24 Oct 2022 17:07:17 -0400 (EDT) In-Reply-To: <867d0pjg9y.fsf@stephe-leake.org> (Stephen Leake's message of "Mon, 24 Oct 2022 10:14:01 -0700") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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: , 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:298429 Archived-At: >> 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. Individual major modes can indeed offer more fine-grained control, but I'm not convinced we want/need that complexity in the generic code. Especially since existing "ELisp backends" (CC-mode, SMIE, and ad-hoc ones) were not written with such piecemeal use in mind, so there's a good chance we'd bump into more bugs. I'd rather start small and later add such refined control if/when this proves to be often necessary, at which point we'll know better what are the pitfalls. >> (add-hook 'treesit-mode-hook #'js--treesit-mode-hook nil t) >> (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? We can't test directly from the major mode function because we don't know yet if `treesit-mode` will be enabled. It'd have to be postponed to `hack-local-variables` anyway. [ IIUC you do that for ada-mode, right? ] > Ah; js--treesit-mode-hook (I object to the name; [ I object too, but I was in a hurry. Now that I have more time to think about it, `js--post-treesit-setup` seems better. ] > But what calls it to do the unset? Minor mode hooks are called both when enabling and disabling the mode. > I set the backend choices in my .emacs, and change them rarely (next Toggling `treesit-mode` dynamically is expected to be rare, indeed. But you might enable `treesit-mode` in a mode-hook and then want to disable it in a child mode's hook. >> 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. My hope is that for a given major mode we'll usually know which functionality should better be offered via `treesit-mode` or via `eglot-mode`. We'll definitely want to allow the user to refine this choice, but I don't think we have enough experience yet with it to know how important it is and what it should look like. Stefan