all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Noah Peart <noah.v.peart@gmail.com>, Yuan Fu <casouri@gmail.com>
Cc: 70361@debbugs.gnu.org
Subject: bug#70361: [PATCH] Add font-locking for operators in go-ts-mode.
Date: Sat, 13 Apr 2024 10:40:09 +0300	[thread overview]
Message-ID: <86mspxr9ra.fsf@gnu.org> (raw)
In-Reply-To: <CAPVBTSejO+khsA6+RKbJ8FD5aOMnP5PxxViLgrCtMdQhguismw@mail.gmail.com> (message from Noah Peart on Sat, 13 Apr 2024 00:32:59 -0700)

> From: Noah Peart <noah.v.peart@gmail.com>
> Date: Sat, 13 Apr 2024 00:32:59 -0700
> Cc: 70361@debbugs.gnu.org
> 
> On a somewhat related note, I was wondering why the treesit modes in emacs
> define their `treesit-font-lock-feature-list`s in the mode definitions.
> 
> Wouldn't it be more user-friendly to `defvar` the feature list?

AFAIR, we do that in the mode's settings because the translation of
general categories into mode-specific settings is not easy, and
because we want users to control that via the fontification level, not
below that.

What problems do you see with the current approach that would require
more fine-grained user control?  And why do you think a defvar is the
proper way of providing such control?





  reply	other threads:[~2024-04-13  7:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-13  5:23 bug#70361: [PATCH] Add font-locking for operators in go-ts-mode Noah Peart
2024-04-13  7:20 ` Eli Zaretskii
2024-04-13  7:27   ` Noah Peart
2024-04-13  7:32     ` Noah Peart
2024-04-13  7:40       ` Eli Zaretskii [this message]
2024-04-13  7:53         ` Noah Peart
2024-04-13  9:33           ` Eli Zaretskii
2024-04-14 23:25 ` Yuan Fu
2024-04-14 23:34 ` Yuan Fu
2024-04-15 12:05   ` Noah Peart
2024-04-16  1:49 ` Randy Taylor
2024-04-16  5:57 ` Yuan Fu
2024-04-16  5:58 ` Yuan Fu
2024-04-16 12:34   ` Eli Zaretskii
2024-04-17  2:47 ` 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

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

  git send-email \
    --in-reply-to=86mspxr9ra.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=70361@debbugs.gnu.org \
    --cc=casouri@gmail.com \
    --cc=noah.v.peart@gmail.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.