unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: casouri@gmail.com, theo@thornhill.no
Cc: 60983@debbugs.gnu.org
Subject: bug#60983: 29.0.60; Tree-sitter user-level control
Date: Thu, 26 Jan 2023 09:27:46 +0200	[thread overview]
Message-ID: <83357xg3gt.fsf@gnu.org> (raw)
In-Reply-To: <83edrli46m.fsf@gnu.org> (message from Eli Zaretskii on Mon, 23 Jan 2023 18:52:33 +0200)

> Cc: 60983@debbugs.gnu.org, theo@thornhill.no
> Date: Mon, 23 Jan 2023 18:52:33 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Theodor Thornhill <theo@thornhill.no>
> > Cc: Yuan Fu <casouri@gmail.com>
> > Date: Sat, 21 Jan 2023 12:48:58 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> 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





  reply	other threads:[~2023-01-26  7:27 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-21 11:11 bug#60983: 29.0.60; Tree-sitter user-level control Eli Zaretskii
2023-01-21 11:48 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-21 12:36   ` Eli Zaretskii
2023-01-21 12:40     ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-23 19:37       ` Yuan Fu
2023-01-23 19:59         ` Eli Zaretskii
2023-01-23 21:08           ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-23 23:55             ` Yuan Fu
2023-01-29 13:33               ` Eli Zaretskii
2023-01-29 19:12                 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-29 19:41                   ` Eli Zaretskii
2023-01-30  2:28                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-30 13:45                       ` Eli Zaretskii
2023-01-24  3:26             ` Eli Zaretskii
2023-01-25 20:12               ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-25 21:16                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-26  8:27                   ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-26  6:08                 ` Eli Zaretskii
2023-01-26  6:25                   ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-23 16:52   ` Eli Zaretskii
2023-01-26  7:27     ` Eli Zaretskii [this message]
2023-01-26  7:37       ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-26  9:08         ` Eli Zaretskii
2023-01-28 13:12       ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-28 13:25         ` Eli Zaretskii
2023-01-28 18:41           ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-29 13:24             ` Eli Zaretskii
2023-01-26  7:56 ` Yuan Fu
2023-02-03  3:07 ` Yuan Fu
2023-02-03  7:47   ` Eli Zaretskii
2023-02-04 23:38     ` Yuan Fu
2023-02-05  6:01       ` Eli Zaretskii
2023-02-05  7:54         ` Yuan Fu
2023-02-05  9:23           ` Eli Zaretskii
2023-02-05  9:42             ` Yuan Fu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83357xg3gt.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=60983@debbugs.gnu.org \
    --cc=casouri@gmail.com \
    --cc=theo@thornhill.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).