From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Noah Peart Newsgroups: gmane.emacs.bugs Subject: bug#70361: [PATCH] Add font-locking for operators in go-ts-mode. Date: Sat, 13 Apr 2024 00:53:45 -0700 Message-ID: References: <86r0f9ranr.fsf@gnu.org> <86mspxr9ra.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000bf73490615f5b03d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23978"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70361@debbugs.gnu.org, Yuan Fu To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 13 09:55:08 2024 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 1rvYE8-00066a-ED for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Apr 2024 09:55:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rvYDv-0004Dl-Qd; Sat, 13 Apr 2024 03:54:55 -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 1rvYDu-0004Ba-0G for bug-gnu-emacs@gnu.org; Sat, 13 Apr 2024 03:54:54 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rvYDt-0005SH-OZ for bug-gnu-emacs@gnu.org; Sat, 13 Apr 2024 03:54:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rvYE3-0006D3-TN for bug-gnu-emacs@gnu.org; Sat, 13 Apr 2024 03:55:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Noah Peart Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Apr 2024 07:55:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70361 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 70361-submit@debbugs.gnu.org id=B70361.171299485823444 (code B ref 70361); Sat, 13 Apr 2024 07:55:03 +0000 Original-Received: (at 70361) by debbugs.gnu.org; 13 Apr 2024 07:54:18 +0000 Original-Received: from localhost ([127.0.0.1]:60023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rvYDH-00065q-N7 for submit@debbugs.gnu.org; Sat, 13 Apr 2024 03:54:17 -0400 Original-Received: from mail-oa1-x34.google.com ([2001:4860:4864:20::34]:54720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rvYDF-00064T-0i for 70361@debbugs.gnu.org; Sat, 13 Apr 2024 03:54:14 -0400 Original-Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-23333dddd8aso973397fac.1 for <70361@debbugs.gnu.org>; Sat, 13 Apr 2024 00:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712994837; x=1713599637; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Gjo9EnM8t0pAUFOPmuT/DntwbAB4UjW15SmyLeAAJ28=; b=AM3XXUTUIRUgBcvAqD5b5yLOeKEVOvi0dYA788DBvTZTjXKsq+vJeMqMph5nZSYnvg VgQYawe43e95Yuqryc2DUVg8sRIx9ILlJtSsd7Y8XCpU7fQcA6/4zsp3nwb8noBX1TZF mVNN99sIbhfJtLVpR7xZZD4GfLJUwEotNkoBpH+vR19opUnEvKxWJHHE8iCSSL4ZsGx3 9kWwVFXPR9jPTiy+kf8Sbari9WIJCH8HRDUJE6ehwJLtZFjXHQg8wLBMrXhD4I6OUNwf 9T+1Kr0z5JK6KwSdFWJ9AhUPOUjMi1xABmBUG7qeo2exyztkWPncrmt7lWS4lqLmAwv4 NIFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712994837; x=1713599637; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Gjo9EnM8t0pAUFOPmuT/DntwbAB4UjW15SmyLeAAJ28=; b=Jh8XO7DgrTc3KK6epnZBVNhCJkrEWZO61tIEz48FdGJzMJK2ZopUskk3X2ZQRn3FV7 BXJGVvr5mMNSqkgWZWipar71szXRoegbK0sYgTyJ2jQCT8551tyRJuyiYqrB1qZ3HUFv jRfyWvTpbY7QncZKK9dMRhrjEhij5GaEXgQc5Zid8ANbfCAiK/ge/DnSgOROhipHAHg9 uDW9WqKuvX/OnRzXYc46eZ+rmhEVUiVOZqPbEcXRuFApEXlWYzOEgwrRAuPGXcIn715h Q6WyktGc+x3ClOvFG4aLUewEG+aO1H76kOI4OEr3+p0bo6swv2/bE14JCi62BPJpWViQ vpxg== X-Forwarded-Encrypted: i=1; AJvYcCXIdEzgEbsNe2Nb62ENnulpEr+sDgWW1zos2El6Rhbtid2vqHMelpLIYmKQWihDMPqUB4I6EQlaBPe0ifKSvLoIouyJAao= X-Gm-Message-State: AOJu0YyuOuHZAVuaUz9umh5gTP1UxiMO+2FBR8OFrhVwcY9h0UxAXCyG XhiXp5JXG1AOvApUHHkl3JmFMk/ZhttqlD/NMjzimPBRdF+ePDvv2mdUnRIQhHjLo0Jo+j4ycsQ FXJqTh41D1+QSJqvCCKnrw/vFWGZILHj9kDMzIQ== X-Google-Smtp-Source: AGHT+IFxp4ZdDo/fvqJ7Ju+0kT+JjNZjFXMLLIKLn/2iatEWI9KNFmswM/mgbFa5yGiRVk8Ou4Alm73UsUyN5/wy8RQ= X-Received: by 2002:a05:6870:b68d:b0:22e:bc50:3492 with SMTP id cy13-20020a056870b68d00b0022ebc503492mr5037006oab.47.1712994836769; Sat, 13 Apr 2024 00:53:56 -0700 (PDT) In-Reply-To: <86mspxr9ra.fsf@gnu.org> 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:283181 Archived-At: --000000000000bf73490615f5b03d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > What problems do you see with the current approach that would require more fine-grained user control? The main issue for me is removing the `error` feature from any mode that adds it with `:override t`. I find the override font-locking is jarring - in some Languages half the buffer can switch in and out of parse errors when you do something as simple as removing a closing paren. Also, allowing users to rearrange features at different levels seems like a bonus. > And why do you think a defvar is the proper way of providing such control= ? You're right, I don't think it's the best way - it's just what I've been doing in treesit modes I've written till now. On Sat, Apr 13, 2024 at 12:40=E2=80=AFAM Eli Zaretskii wrote= : > > From: Noah Peart > > 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? > --000000000000bf73490615f5b03d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> What problems do you see with the current approach th= at would require
more fine-grained user control?

The = main issue for me is removing the `error` feature from any mode
t= hat adds it with `:override t`. I find the override font-locking is jarring= - in some
Languages half the buffer can switch in and out of par= se errors when you
do something as simple as removing a closing p= aren.

Also, allowing users to rearrange features a= t different levels seems like a bonus.

> And wh= y do you think a defvar is the proper way of providing such control?
<= div>
You're right, I don't think it's the best wa= y - it's just what I've been doing in
treesit=C2=A0modes = I've written till now.

On Sat, Apr 13, 2024 at 12:40=E2=80=AFAM El= i Zaretskii <eliz@gnu.org> wrote:=
> From: Noah= Peart <noah= .v.peart@gmail.com>
> Date: Sat, 13 Apr 2024 00:32:59 -0700
> Cc: 70361@d= ebbugs.gnu.org
>
> On a somewhat related note, I was wondering why the treesit modes in e= macs
> 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?=C2=A0 And why do you think a defvar is the<= br> proper way of providing such control?
--000000000000bf73490615f5b03d--