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.bugs Subject: bug#60983: 29.0.60; Tree-sitter user-level control Date: Thu, 26 Jan 2023 09:27:46 +0200 Message-ID: <83357xg3gt.fsf@gnu.org> References: <83tu0kkuqo.fsf@gnu.org> <87tu0k3y6t.fsf@thornhill.no> <83edrli46m.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12793"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60983@debbugs.gnu.org To: casouri@gmail.com, theo@thornhill.no Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 26 08:28:16 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pKwgB-0003BP-NU for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Jan 2023 08:28:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pKwg0-0002DG-Gj; Thu, 26 Jan 2023 02:28:04 -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 1pKwfy-0002Cy-RJ for bug-gnu-emacs@gnu.org; Thu, 26 Jan 2023 02:28:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pKwfy-0002Hz-JL for bug-gnu-emacs@gnu.org; Thu, 26 Jan 2023 02:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pKwfy-000599-A9 for bug-gnu-emacs@gnu.org; Thu, 26 Jan 2023 02:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jan 2023 07:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60983 X-GNU-PR-Package: emacs Original-Received: via spool by 60983-submit@debbugs.gnu.org id=B60983.167471807419768 (code B ref 60983); Thu, 26 Jan 2023 07:28:02 +0000 Original-Received: (at 60983) by debbugs.gnu.org; 26 Jan 2023 07:27:54 +0000 Original-Received: from localhost ([127.0.0.1]:60491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKwfp-00058l-Qj for submit@debbugs.gnu.org; Thu, 26 Jan 2023 02:27:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKwfk-00058V-NK for 60983@debbugs.gnu.org; Thu, 26 Jan 2023 02:27:52 -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 1pKwfe-0002Ch-43; Thu, 26 Jan 2023 02:27:42 -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=ZKTkLm/GTIH83lKmFKJLyYLEBjmmVoS1hgKeqsbZRZw=; b=nWlGYlfQzZq4 07jSi0VqH8aiPyvKC3tPy90jNYt5s+RZBSzNNEKdlX4NraxTFcIV6GWdELjkkVhbKbSieLK7hYjua tSHUkbGJ48klMuUGdFnBLnUMIs6lh9lVahpGVyr/kk2x0p4n6rj5yB1g9X7m34l4+Q+LGrODJq+Oy IoWDhxxQ9k4CeEepXRZy0kGxWL6IWRvnymVC5rZtHi7cM4jlqq4PoeOJUo/q6KtmfJLdwgZy069n4 y45LZuglRaLrCMUJbQAQTyFFeMx5fyO13Q1pf5SB8UZG9ZlRYs5uJx0ahIU9mY46whrrTFcXzlHkw T6zpcReFClRWMZbYYwV3IQ==; 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 1pKwfS-0005J3-Qh; Thu, 26 Jan 2023 02:27:41 -0500 In-Reply-To: <83edrli46m.fsf@gnu.org> (message from Eli Zaretskii on Mon, 23 Jan 2023 18:52:33 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:254177 Archived-At: > Cc: 60983@debbugs.gnu.org, theo@thornhill.no > Date: Mon, 23 Jan 2023 18:52:33 +0200 > From: Eli Zaretskii > > > From: Theodor Thornhill > > Cc: Yuan Fu > > Date: Sat, 21 Jan 2023 12:48:58 +0100 > > > > Eli Zaretskii writes: > > > > > I started looking into providing user-level documentation for > > > tree-sitter based modes, and bumped into some issues: > > > > > > . How does one use treesit-font-lock-level? > > > > > > - It is not a customizable user option (unlike > > > font-lock-maximum-decoration), so it cannot be set via > > > customize-variable. Is there a reason not to make it a > > > defcustom? > > > - It automatically becomes buffer-local when set, and OTOH setting > > > it in a buffer does not produce fontifications according to the > > > level, and neither does setting it in a mode hook. So the only > > > way to change its value is by using setq-default, which I don't > > > think is the intent? > > > - Should we make the variable a defcustom? > > > - Should it be possible to customize it separately for each mode? > > > - Should we allow to change the level and then call some function > > > to re-fontify the current buffer according to the new level? > > > > I struggled with this too. I ended up setting it with setq-default, > > assuming I was just missing something very simple. I'm in favor for > > either a defcustom or honoring the font-lock-maximum-decoration values, > > specifically these settings: > > > > ``` > > If t, use the maximum decoration available. > > If a number, use that level of decoration (or if not available the maximum). > > ``` Let's just make it a defcustom for now, with the values it has today, including the default. The problems with honoring the value of font-lock-maximum-decoration are that (a) its default value is t in most (all?) modes, whereas we decided not to use 4 as the default value of treesit-font-lock-level; and (b) if changing treesit-font-lock-level's value doesn't require to kill the buffer and revisit the file (as I hope we will make it work), the instructions regarding changing the value of font-lock-maximum-decoration will depend on whether the mode does or doesn't use tree-sitter, which will make the instructions confusingly complex. Yuan or Theo, would one of you please make the change of making treesit-font-lock-level a defcustom, with a proper :set functions to avoid the need to revisit the file? My hands are too full ATM, and this issue is basically the only one which prevents me from updating the Emacs user manual with the tree-sitter info, which in turn is the only issue that blocks the move to releasing the 29.0.90 pretest tarball. TIA