Received: (at 71345) by debbugs.gnu.org; 5 Jun 2024 17:01:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 05 13:01:12 2024
Received: from localhost ([127.0.0.1]:49107 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sEu0d-0002N7-RX
for submit <at> debbugs.gnu.org; Wed, 05 Jun 2024 13:01:12 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45234)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sEu0c-0002Ml-BV
for 71345 <at> debbugs.gnu.org; Wed, 05 Jun 2024 13:01:10 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D2188809C2;
Wed, 5 Jun 2024 13:00:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1717606849;
bh=a+g5Y/h+3nz7RmZnNQ2Gy9RfmGzLu8aGQpjcUoTvYHg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=EBFV+VHXSS0ot1jvcEKhU7Nx1/WiPK3QB49Cve7MOgnQbjt3xGgv5KT+pU8P80yDq
192vM19VUfDBUIFb3u3pM02od/bYsS/mXyhDCUiecmemvGr9lAfEW79zWPncJE2W+N
JgAcfklX43Hiqyzo95lXcI4dQEeZlTC9PDGJjRmcYFVj6x6pN8QERF6nGoyWyX5Imw
QRB2oUT8Kmx8ZBs956qC5yYwZqX4nr6IiUEQv78a6gwnxuATy+Uy2auQ9HDv1vFE5+
wkbJgv521z5Kfqemj32LxW+y6nxlWWaIvBRbmr7UBsPysiL2EOMku74kzGw3cJZEzl
BEj+ex+o+Yrzg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C3E0B8057E;
Wed, 5 Jun 2024 13:00:49 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B54E112045A;
Wed, 5 Jun 2024 13:00:49 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#71345: Feature: unleash font-lock's secret weapon; handle
Qfontified = non-nil
In-Reply-To: <86a5jzjvar.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 05 Jun
2024 17:53:00 +0300")
Message-ID: <jwva5jzjpeu.fsf-monnier+emacs@HIDDEN>
References: <86msnzk4pl.fsf@HIDDEN>
<64828D71-7A1D-4826-811A-A30E870358C7@HIDDEN>
<86a5jzjvar.fsf@HIDDEN>
Date: Wed, 05 Jun 2024 13:00:49 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.010 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71345
Cc: 71345 <at> debbugs.gnu.org, JD Smith <jdtsmith@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> 1 Make font-lock a good citizen by using its own alias for face.=20
>> 2 Give other jit-lock backends which may alter face and potentially
>> conflict with font-lock the ability to specify
>> to jit-lock =E2=80=9Cif you re-run font lock on a region, re-run me too=
after that.=E2=80=9D
>
> I don't understand. The solution to this dilemma is well known: Lisp
> programs that want to control faces without turning off font-lock mode
> should set font-lock-face property, instead of the face property. Why
> do you need to find another solution?
Another solution to that dilemma was to use overlays. =F0=9F=99=82
Stefan
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.Received: (at 71345) by debbugs.gnu.org; 5 Jun 2024 16:55:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 05 12:55:45 2024 Received: from localhost ([127.0.0.1]:48648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sEtvL-00024J-Lk for submit <at> debbugs.gnu.org; Wed, 05 Jun 2024 12:55:44 -0400 Received: from mail-qk1-f170.google.com ([209.85.222.170]:59822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jdtsmith@HIDDEN>) id 1sEtvJ-00023v-Hj for 71345 <at> debbugs.gnu.org; Wed, 05 Jun 2024 12:55:42 -0400 Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-7951c762462so123433185a.3 for <71345 <at> debbugs.gnu.org>; Wed, 05 Jun 2024 09:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717606461; x=1718211261; darn=debbugs.gnu.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=UhMWd0IwffqI6goObncbQZaymi+fDdahkQZzHt+zUok=; b=BC5izSW2HyFhvF8Q8WjVQrs0qskRvVn5gb0TvI2queo3UnxV22QUX7lboeiLYmMdQG cUbm3d3deDxrQXypkuQXXfW7C+7dFFvWFrMzZ/F7nlC28mKeOwb9eO+7bRnBCoyhJpST +f4xk8BbjQFUymSdB04+KtezxE/Jy4mP0EpE0pb8qF3BwH3dOgM+yZl8P8SgTw9gaaLJ skWGwFqdapaKRKRKXkg5Tk+qyhFk51W+/0EKpjUSNXSpWSS++o3E8tce6Gd4rRyy8dhO zf3dOzbO1fuKY2n9yScSXCNxwWSw5mSJ+4g06uLkXC5oFs/9fBe5XzcqS1bysIiB923F gEnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717606461; x=1718211261; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UhMWd0IwffqI6goObncbQZaymi+fDdahkQZzHt+zUok=; b=NfktNqTvAna3pz6+FEhaeXaa28JTddDM2/HVO4aTGbFy+lSekCMI1IiWZkrGqwai89 0S7rcUA+zGpaVsI9TTw4uqXUF9dUvQ6ief8Gz/bxpoTT1sdElRoH3HsY41ue8jtETDVk pUG+hNlpkHRfKLR/31ab/2aG9qE86DAEKSVU52CMbMjnS+DrBK4zW0J9niYVGjJsQj3b 1KiEUe1OZsNMIX/vg2NaHxaCwHtyGwX84iVw80M6lZcAPQtHv6W/HSwwcThvcKiL+uRS cCb6DsPWWETs/dSD15pTVL12JAS5xZTHIPqfIsyewFNTtiO/xMypG4OGSEnsarnA3jhh T8iA== X-Forwarded-Encrypted: i=1; AJvYcCXIG9tIV32W1m1Y1/jxKJkhDC7AIK++MvYlHFwg6YHFN9HtUkmLv+qXGz0ECTI1G/fRqgi83ddx+WF/fu58va1vp6+vqAg= X-Gm-Message-State: AOJu0YxWkjRWVWCOUn3CfzN9bXTvclzxyihBChxqAk29okwB29oHkPLH hFB/qFeS7FEHWUY7MaG2b2nB8miDKznNyUjic2xBMbzudY+mL0Z7o+CYCg== X-Google-Smtp-Source: AGHT+IHjCvdUElu6oYFCIH8ke4pxF0zKvDp9uc2wps8z9hz4JVYWylcjEvVtFD5kmgA1A5Q3KlX7lg== X-Received: by 2002:ac8:590d:0:b0:43a:f949:85b9 with SMTP id d75a77b69052e-4402b61bb4fmr37822821cf.32.1717602769800; Wed, 05 Jun 2024 08:52:49 -0700 (PDT) Received: from smtpclient.apple ([131.183.131.33]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-43ff2589b87sm60967621cf.86.2024.06.05.08.52.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jun 2024 08:52:49 -0700 (PDT) From: JD Smith <jdtsmith@HIDDEN> Message-Id: <9B55EAF1-C0FC-4B5B-A438-3B3C33430816@HIDDEN> Content-Type: multipart/alternative; boundary="Apple-Mail=_1601438C-A456-489C-90F9-02F0CA7219DD" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: bug#71345: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil Date: Wed, 5 Jun 2024 11:52:37 -0400 In-Reply-To: <86a5jzjvar.fsf@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> References: <86msnzk4pl.fsf@HIDDEN> <64828D71-7A1D-4826-811A-A30E870358C7@HIDDEN> <86a5jzjvar.fsf@HIDDEN> X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71345 Cc: 71345 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --Apple-Mail=_1601438C-A456-489C-90F9-02F0CA7219DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 5, 2024, at 10:53=E2=80=AFAM, Eli Zaretskii <eliz@HIDDEN> = wrote: >=20 >> From: JD Smith <jdtsmith@HIDDEN> >> Cc: monnier@HIDDEN, 71345 <at> debbugs.gnu.org >> Date: Wed, 5 Jun 2024 10:02:23 -0400 >>=20 >> In general, yes. In my case having the scope be per-buffer not per = window makes the most sense in >> terms of >>=20 >> the functionality. >>=20 >> Given the feature of redisplay I just mentioned, you will actually = get >>=20 >> a per-window functionality, at least as far as the position of point >>=20 >> is concerned. >>=20 >> Not in my case, since I am discriminating between point in the = selected window and other windows showing the >> same buffer, such that switching windows =3D changing point. Since = much of the work in my mode is not >> position-dependent but depends on text content, updating face is the = natural thing. =20 >=20 > Sorry, I don't think I understand you. But if the fact that redisplay > moves point to window-point doesn't bother me, we can drop this issue. I use treesitter to identify nodes of interest, and do that in a PCH. = So there is one buffer-local record of where that node of interest is. = Thus different windows showing the same buffer is immaterial; the window = where the last PCH ran controls. >> Thinking more about what makes font-lock =E2=80=9Cspecial=E2=80=9D as = a jit-lock backend, it is exactly this: font-lock claims >> exclusive ownership of `face'. Solutions I can see: >>=20 >> 1 Make font-lock a good citizen by using its own alias for face.=20 >> 2 Give other jit-lock backends which may alter face and potentially = conflict with font-lock the ability to specify >> to jit-lock =E2=80=9Cif you re-run font lock on a region, re-run me = too after that.=E2=80=9D >=20 > I don't understand. The solution to this dilemma is well known: Lisp > programs that want to control faces without turning off font-lock mode > should set font-lock-face property, instead of the face property. Why > do you need to find another solution? Because such programs may need to override locations where font-lock has = already applied 'face. In contrast to the documentation[1], font-lock = does not itself use font-lock-face, but only configures it for other = programs to use. The issue is that 'face, where applied, always = outranks any alias to 'face placed on the same text: >>>>>>=20 ;; TEST (1st disable font-lock-mode) (push 'my-face-prop (alist-get 'face char-property-alias-alist)) (put-text-property 1 8 'face 'error) (put-text-property 1 8 'my-face-prop 'success) ; outranked by 'face (remove-text-properties 1 8 '(face nil)) ; now we can see my-face-prop <<<<<<< It would be wonderful if font-lock cleared and applied a suitable face = alias (perhaps 'font-lock-face itself). This is what I mean by making = font-lock a "good citizen": let other backends be able to override the = faces it sets. Currently, if font-lock-mode is enabled, it has = effectively exclusive rights to the use of 'face on the locations it = matches. The only hope then is to arrange to run after font-lock, and = use the "heavy hammer" of overwriting 'face yourself. [1] =46rom `Search-based Fontification':=20 If it is =E2=80=98prepend=E2=80=99, the face specified by FACESPEC is = added to the beginning of the =E2=80=98font-lock-face=E2=80=99 property. = If it is =E2=80=98append=E2=80=99, the face is added to the end of the = =E2=80=98font-lock-face=E2=80=99 property. But I believe all font-lock keywords actually just set the 'face = property.= --Apple-Mail=_1601438C-A456-489C-90F9-02F0CA7219DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;"><br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On Jun 5, 2024, at 10:53=E2=80=AFAM, Eli Zaretskii = <eliz@HIDDEN> wrote:</div><br = class=3D"Apple-interchange-newline"><div><meta = charset=3D"UTF-8"><blockquote type=3D"cite" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; orphans: auto; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;">From: JD Smith <jdtsmith@HIDDEN><br>Cc: = monnier@HIDDEN, 71345 <at> debbugs.gnu.org<br>Date: Wed, 5 Jun 2024 = 10:02:23 -0400<br><br>In general, yes. In my case having the scope = be per-buffer not per window makes the most sense in<br>terms = of<br><br>the functionality.<br><br>Given the feature of redisplay I = just mentioned, you will actually get<br><br>a per-window functionality, = at least as far as the position of point<br><br>is concerned.<br><br>Not = in my case, since I am discriminating between point in the selected = window and other windows showing the<br>same buffer, such that switching = windows =3D changing point. Since much of the work in my mode is = not<br>position-dependent but depends on text content, updating face is = the natural thing. <br></blockquote><br style=3D"caret-color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = normal; font-variant-caps: normal; font-weight: 400; letter-spacing: = normal; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">Sorry, = I don't think I understand you. But if the fact that = redisplay</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">moves point to = window-point doesn't bother me, we can drop this issue.</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: = none;"></div></blockquote><div><br></div><div>I use treesitter to = identify nodes of interest, and do that in a PCH. So there is one = buffer-local record of where that node of interest is. Thus = different windows showing the same buffer is immaterial; the window = where the last PCH ran controls.</div><br><blockquote = type=3D"cite"><div><blockquote type=3D"cite" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; orphans: auto; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;">Thinking more about what makes font-lock = =E2=80=9Cspecial=E2=80=9D as a jit-lock backend, it is exactly this: = font-lock claims<br>exclusive ownership of `face'. Solutions I can = see:<br><br>1 Make font-lock a good citizen by using its own alias for = face.<span class=3D"Apple-converted-space"> </span><br>2 Give other = jit-lock backends which may alter face and potentially conflict with = font-lock the ability to specify<br>to jit-lock =E2=80=9Cif you re-run = font lock on a region, re-run me too after that.=E2=80=9D<br></blockquote>= <br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">I don't understand. = The solution to this dilemma is well known: Lisp</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">programs that want to control faces without = turning off font-lock mode</span><br style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">should = set font-lock-face property, instead of the face property. = Why</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">do you need to find = another solution?</span></div></blockquote></div><br><div>Because such = programs may need to <i>override </i>locations where font-lock has = already applied 'face. In contrast to the documentation[1], = font-lock does not itself use font-lock-face, but only configures it for = other programs to use. The issue is that 'face, where applied, = always outranks any alias to 'face placed on the same = text:</div><div><br></div><div>>>>>>> </div><div><d= iv>;; TEST <span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, = 0, 0);">(1st disable font-lock-mode)</span></div><div>(push = 'my-face-prop (alist-get 'face = char-property-alias-alist))</div><div>(put-text-property 1 8 'face = 'error)</div><div>(put-text-property 1 8 'my-face-prop 'success) ; = outranked by 'face</div><div>(remove-text-properties 1 8 '(face nil)) ; = now we can see = my-face-prop</div></div><div><<<<<<<</div><div><br></= div><div>It would be wonderful if font-lock cleared and applied a = suitable face alias (perhaps 'font-lock-face itself). This is what = I mean by making font-lock a "good citizen": let other backends be able = to override the faces it sets. Currently, if font-lock-mode is = enabled, it has effectively exclusive rights to the use of 'face on the = locations it matches. The only hope then is to arrange to run = after font-lock, and use the "heavy hammer" of overwriting 'face = yourself.</div><div><br></div><div><div>[1] =46rom `Search-based = Fontification': </div><blockquote style=3D"margin: 0px 0px 0px = 40px; border: medium; padding: 0px;"><span style=3D"caret-color: rgb(0, = 0, 0); color: rgb(0, 0, 0);">If it is =E2=80=98prepend=E2=80=99, the = face specified by FACESPEC is</span><span style=3D"caret-color: rgb(0, = 0, 0); color: rgb(0, 0, 0);"> added to the beginning of the = =E2=80=98font-lock-face=E2=80=99 property. If it is =E2=80=98append=E2= =80=99, the face is added to the end of the =E2=80=98font-lock-face=E2=80=99= property.</span></blockquote><font color=3D"#000000">But I believe all = font-lock keywords actually just set the 'face = property.</font></div></body></html>= --Apple-Mail=_1601438C-A456-489C-90F9-02F0CA7219DD--
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.
Received: (at 71345) by debbugs.gnu.org; 5 Jun 2024 16:55:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 05 12:55:15 2024
Received: from localhost ([127.0.0.1]:48603 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sEtus-00022n-6U
for submit <at> debbugs.gnu.org; Wed, 05 Jun 2024 12:55:15 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:2283)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sEtUt-0006Rc-BG
for 71345 <at> debbugs.gnu.org; Wed, 05 Jun 2024 12:28:23 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 55A94444B9F;
Wed, 5 Jun 2024 12:28:03 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1717604881;
bh=EDvztW8IDF3rzcxdp84/Ri/mi2egtRWyao6IRQcrxl4=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=SfffDe6/C50uhdbJez2xxUb76mVKA7795+AmGWVQ2Ff24GXGbm2KS21L1pGVYg3PB
imY28yFQw5WFT53ek9URqjILIwFGrBTojyIhMH1TcV7/SBWcdtSMFVjqjiPfcfAtcw
1wBB3JXY95JHyF8VEC0y4BWkeZyE+We8kNQOBs3DgjD/kK0BXj9GPC8k08QZsE2O08
MaZT0rczNt9PjuZJssoP15qvDjFq7fHPxImG7vPcpMxU/VAmACTS7wkOuMHq01r64t
Ne5JXQjwe1wUo5nRqmWA2Xr/KFPH9A0mKZkeu+mVcGKeD2k2suGOlY8jUNM8k3U6J+
plz5YU9OJ6akA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DB26F444B9E;
Wed, 5 Jun 2024 12:28:01 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C7DFD1203DA;
Wed, 5 Jun 2024 12:28:01 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#71345: Feature: unleash font-lock's secret weapon; handle
Qfontified = non-nil
In-Reply-To: <86o78fk4ye.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 05 Jun
2024 14:24:25 +0300")
Message-ID: <jwvr0dbjr0r.fsf-monnier+emacs@HIDDEN>
References: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN>
<jwvzfs29dyy.fsf-monnier+emacs@HIDDEN>
<1F2B8726-7594-494F-AB9D-08C48B7BCC43@HIDDEN>
<jwvtti9lcf0.fsf-monnier+emacs@HIDDEN>
<DAC8D262-0862-45ED-BD3A-D95ED5FE9793@HIDDEN>
<jwvmso0951x.fsf-monnier+emacs@HIDDEN>
<798B70AF-69BD-479E-992E-5CE9B4924820@HIDDEN>
<jwved9cl7ld.fsf-monnier+emacs@HIDDEN> <86o78fk4ye.fsf@HIDDEN>
Date: Wed, 05 Jun 2024 12:28:01 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.245 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71345
Cc: 71345 <at> debbugs.gnu.org, jdtsmith@HIDDEN, dmitry@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> Because a given buffer can have several (window-)points,
>> position-dependent highlighting will ideally want to be added via
>> (window-specific) overlays rather than text-properties.
>
> Not sure I understand how this remark is relevant to the issue
> discussed here, but let me just point out that when redisplay starts
> working on a window, it temporarily moves point to the window-point
> position. So position-dependent highlighting will behave in each
> window according to its window-point, which I think is what's expected
> here?
But the highlighting is done "once and for all" (at least until the next
command), so if you want it to be different in different windows (to
reflect the different values of `point` in those windows) you'll need
overlays with the `window` property because the highlighting will not be
re-done in the middle of redisplay when we go from one window to another.
Stefan
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.Received: (at 71345) by debbugs.gnu.org; 5 Jun 2024 16:38:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 05 12:38:42 2024 Received: from localhost ([127.0.0.1]:47560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sEtes-0006yG-3L for submit <at> debbugs.gnu.org; Wed, 05 Jun 2024 12:38:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sEteq-0006xw-2X for 71345 <at> debbugs.gnu.org; Wed, 05 Jun 2024 12:38:41 -0400 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 <eliz@HIDDEN>) id 1sEteV-0000ZY-SA; Wed, 05 Jun 2024 12:38:19 -0400 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=vQ/SgRAy8nT3C6ft1Fpnir5Z8wmVdkJ0k9FN7+NyRVU=; b=Vf/f0vUUKnJ6 VcpXxX1+/wnpB3dUt1WLNB9iSDzuiHSSewgPu5BL0zChbUwJBBeN2amKuk89LUm+yySrW196UZKE4 1emYAsFdGnDllBLpQEm661M9RZuf5IM6y+Tr81ew45N9BDVdUDdYnI6Kp2VBoNi4GmvCAN8/15PbQ Rv3ZznJEAhtrIHsh6BbDFzKYcWwNo1G0S9eOoOTtdzfWzJ6arEpBg4CiOKQgIMxfgPPCIloqBGoLo vABYDskm1gdon5ruAUzoFmak4LbPKFyWyJ+HwIGDESxRCEIbbtsMMS5m0S1Id5zI0wp1AzdVTkDNc ShILmUOqFBlc1NofXPEbzA==; Date: Wed, 05 Jun 2024 19:38:16 +0300 Message-Id: <865xunjqfb.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvr0dbjr0r.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Wed, 05 Jun 2024 12:28:01 -0400) Subject: Re: bug#71345: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil References: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN> <jwvzfs29dyy.fsf-monnier+emacs@HIDDEN> <1F2B8726-7594-494F-AB9D-08C48B7BCC43@HIDDEN> <jwvtti9lcf0.fsf-monnier+emacs@HIDDEN> <DAC8D262-0862-45ED-BD3A-D95ED5FE9793@HIDDEN> <jwvmso0951x.fsf-monnier+emacs@HIDDEN> <798B70AF-69BD-479E-992E-5CE9B4924820@HIDDEN> <jwved9cl7ld.fsf-monnier+emacs@HIDDEN> <86o78fk4ye.fsf@HIDDEN> <jwvr0dbjr0r.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71345 Cc: 71345 <at> debbugs.gnu.org, jdtsmith@HIDDEN, dmitry@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: jdtsmith@HIDDEN, 71345 <at> debbugs.gnu.org, dmitry@HIDDEN > Date: Wed, 05 Jun 2024 12:28:01 -0400 > > >> Because a given buffer can have several (window-)points, > >> position-dependent highlighting will ideally want to be added via > >> (window-specific) overlays rather than text-properties. > > > > Not sure I understand how this remark is relevant to the issue > > discussed here, but let me just point out that when redisplay starts > > working on a window, it temporarily moves point to the window-point > > position. So position-dependent highlighting will behave in each > > window according to its window-point, which I think is what's expected > > here? > > But the highlighting is done "once and for all" (at least until the next > command), so if you want it to be different in different windows (to > reflect the different values of `point` in those windows) you'll need > overlays with the `window` property because the highlighting will not be > re-done in the middle of redisplay when we go from one window to another. In that case, we are in trouble anyway, because the "once and for all" highlighting could be (by sheer luck) be done by display code that doesn't run as part of redisplay, but as part of something else, like vertical-motion.
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.Received: (at 71345) by debbugs.gnu.org; 5 Jun 2024 14:55:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 05 10:55:38 2024 Received: from localhost ([127.0.0.1]:40564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sEs37-0002FE-4b for submit <at> debbugs.gnu.org; Wed, 05 Jun 2024 10:55:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sEs34-0002Ep-To for 71345 <at> debbugs.gnu.org; Wed, 05 Jun 2024 10:55:36 -0400 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 <eliz@HIDDEN>) id 1sEs0f-0007F6-4X; Wed, 05 Jun 2024 10:53:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=yTYqgtgx7fu2bOoGeGUTjELEGIXft5hKyMDcceGDKzE=; b=FGZZb+Mi+nswBFf6lJ91 B0XDRjWqELC9mlic9R5v05Y46c49R47HUGe3oBI6/nC+F57uVpxK0Pi7krNbon/Wxcr5vF2hSmcpm Og548QHasAHNI+2Xf2rpmFTsp851BcoLEwTNhV8QwtJGtrBnFevqnbHFkpPJgH3qltirRSoStURP0 u+yE8aLsyHnyI0JYLSi32kVxEId1MjKfwzFPu5rvWDWcrTMk4QXMiI7XcmZY7tDIbEz95xxCEiD2g b8pJB29/0PMfO7bauu1T69OsO3x7R90/y/I+ZgY6U7+40qxqoG1MCA0kw4/VPSZj4jsKcIcBMW2YU CHUdVo8Jkawx8g==; Date: Wed, 05 Jun 2024 17:53:00 +0300 Message-Id: <86a5jzjvar.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: JD Smith <jdtsmith@HIDDEN> In-Reply-To: <64828D71-7A1D-4826-811A-A30E870358C7@HIDDEN> (message from JD Smith on Wed, 5 Jun 2024 10:02:23 -0400) Subject: Re: bug#71345: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil References: <86msnzk4pl.fsf@HIDDEN> <64828D71-7A1D-4826-811A-A30E870358C7@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71345 Cc: 71345 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: JD Smith <jdtsmith@HIDDEN> > Cc: monnier@HIDDEN, 71345 <at> debbugs.gnu.org > Date: Wed, 5 Jun 2024 10:02:23 -0400 > > In general, yes. In my case having the scope be per-buffer not per window makes the most sense in > terms of > > the functionality. > > Given the feature of redisplay I just mentioned, you will actually get > > a per-window functionality, at least as far as the position of point > > is concerned. > > Not in my case, since I am discriminating between point in the selected window and other windows showing the > same buffer, such that switching windows = changing point. Since much of the work in my mode is not > position-dependent but depends on text content, updating face is the natural thing. Sorry, I don't think I understand you. But if the fact that redisplay moves point to window-point doesn't bother me, we can drop this issue. > Thinking more about what makes font-lock “special” as a jit-lock backend, it is exactly this: font-lock claims > exclusive ownership of `face'. Solutions I can see: > > 1 Make font-lock a good citizen by using its own alias for face. > 2 Give other jit-lock backends which may alter face and potentially conflict with font-lock the ability to specify > to jit-lock “if you re-run font lock on a region, re-run me too after that.” I don't understand. The solution to this dilemma is well known: Lisp programs that want to control faces without turning off font-lock mode should set font-lock-face property, instead of the face property. Why do you need to find another solution?
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.Received: (at 71345) by debbugs.gnu.org; 5 Jun 2024 14:25:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 05 10:25:13 2024 Received: from localhost ([127.0.0.1]:38591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sErZg-0000s1-9L for submit <at> debbugs.gnu.org; Wed, 05 Jun 2024 10:25:13 -0400 Received: from mail-ot1-f41.google.com ([209.85.210.41]:42360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jdtsmith@HIDDEN>) id 1sErON-0000Jr-JP for 71345 <at> debbugs.gnu.org; Wed, 05 Jun 2024 10:13:32 -0400 Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-6f91152ff00so414503a34.1 for <71345 <at> debbugs.gnu.org>; Wed, 05 Jun 2024 07:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717596731; x=1718201531; darn=debbugs.gnu.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=7dAxlFx9hYHUumk5WKKKz6w0ZvMcL4LZsJPdCP23iFQ=; b=ioveUu3Fo2p4pU6JAxaNVcmuo/vSKRra9Zmj64Iy+oDcf00YF4kBiDoKPCVEXJVPZG qv8TnRE6ogNjwQYvDf6n9N4iLvJ1DrqtAL6zxuM9VZ0LJkNKNswCAek5ffZwSFyK5+yc ZJmvMOABCGLQrUyq7xuJkHfszG3X4PdEDP+jFvAN+oP8qOx7H51O44w1k4QgTU74GkIw 9v9ZvwYVG2UNkaKFYe0cqZjjESwzWWstsWtOLanUCVXY47424rom2zWGdzUysIZpiTN1 brNDizQogHoMlae3i+yWVBcaTZrHTTKnZaiip0mlP90y/VzLGZACeB+HnVMQbbdceFME 6VMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717596731; x=1718201531; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7dAxlFx9hYHUumk5WKKKz6w0ZvMcL4LZsJPdCP23iFQ=; b=DQtDWwnk7qDK61WVLZNaS7e50K+HwsgmIDyVQzgsfGeKaZxoo6x+3flm4PddqpklNs OTLvLsGEh+dZ4NCGz6A6I9uLNp/t/xqXPtXvo7XSqdlfndUkARt8ppT5MYwUdUzl2B8I NeZCImz3vax6HNwqoNrYhofUlOPwRY8Wdreo8qQLsfDRab736DcDTiy5ulZ57Tj6eZte MPBzgDNI/ep/OXG1hPMntjvOTMNMWcIERaawBTzV+fBfDRlgag+CRu+417PGdqlEgGU6 8Oi5FHy1zq0EasMQj7Xurv+37pbRnottiU/QPyjzVcy1+LAB/pKrtvYe5odGCHw1w26q O7xQ== X-Forwarded-Encrypted: i=1; AJvYcCVYyW1+zkBp9gY8O60tPcDT9x3+axllDlDsRnBLpt2ccF74Be+ycLAwW+t9bm4jYwntmjKlUmkKHZLOxxF1C/hfreAe2n8= X-Gm-Message-State: AOJu0YxH125C28lq7C3EV5S5Qxj0U4h0NcuWM+aPrXY46YBDSFtP5lFJ TlC1+u3arSTmM1b+xj2goYmyDSCry9hpjMh7/fdUtdt/nlH2GHqxbKHZZw== X-Google-Smtp-Source: AGHT+IEYXe4WAlULKzmm93iJQuWEeIkJVOmyKpyH0K49Eao6G3EToP70mS+lmeBIZrEWdtKOMxv+Gw== X-Received: by 2002:a05:620a:22c9:b0:790:9f13:2ed0 with SMTP id af79cd13be357-79522fdfff7mr432957085a.22.1717596341612; Wed, 05 Jun 2024 07:05:41 -0700 (PDT) Received: from smtpclient.apple ([198.30.180.100]) by smtp.gmail.com with ESMTPSA id af79cd13be357-794f3061475sm444472885a.74.2024.06.05.07.05.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Jun 2024 07:05:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: JD Smith <jdtsmith@HIDDEN> Mime-Version: 1.0 (1.0) Subject: Re: bug#71345: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil Date: Wed, 5 Jun 2024 10:05:30 -0400 Message-Id: <9EDFE1A3-258C-41AC-A457-4A09F1B73A9F@HIDDEN> References: <86o78fk4ye.fsf@HIDDEN> In-Reply-To: <86o78fk4ye.fsf@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> X-Mailer: iPhone Mail (21F90) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71345 Cc: 71345 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, dmitry@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > On Jun 5, 2024, at 7:24=E2=80=AFAM, Eli Zaretskii <eliz@HIDDEN> wrote: >=20 > position-dependent highlighting will behave in each > window according to its window-point, which I think is what's expected > here? In general that would be true. In my case I use a timer-protected post-comma= nd hook to update the (single per buffer) containing treesitter node.=20=
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.Received: (at 71345) by debbugs.gnu.org; 5 Jun 2024 14:03:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 05 10:03:57 2024 Received: from localhost ([127.0.0.1]:37124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sErF7-0008KH-2B for submit <at> debbugs.gnu.org; Wed, 05 Jun 2024 10:03:57 -0400 Received: from mail-qk1-f175.google.com ([209.85.222.175]:44220) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jdtsmith@HIDDEN>) id 1sErF5-0008K2-KA for 71345 <at> debbugs.gnu.org; Wed, 05 Jun 2024 10:03:56 -0400 Received: by mail-qk1-f175.google.com with SMTP id af79cd13be357-79524f6693dso57863085a.0 for <71345 <at> debbugs.gnu.org>; Wed, 05 Jun 2024 07:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717596156; x=1718200956; darn=debbugs.gnu.org; h=to:references:message-id:date:cc:in-reply-to:from:subject :mime-version:content-transfer-encoding:from:to:cc:subject:date :message-id:reply-to; bh=gLKh/AK0cCAlaDiiAYYgR2lg0fhgWW804UNF5+SKj6U=; b=CgW/1EoQA3bZwP1qPZpQhNBgKsqfAJtSKs9A0yg7IcfBS3MXORkj1XtIMwHwBWPV7n 40HItrCx5BKoCRw963netNpIkJhVH9+O1pdyyJK/joTLFS+qTL0i+kqwOsCB8Uht2uAt ImXDjubYwtB2T8/+wU7lsElEDeEHvbNDo6NeM5x2XScW5fHu0+kinqJJ6ouodpovaRS/ JnFdRX6TEN3O2RvkXPHCI1IRWczDi8KpDygiqWC7X0ts+3CLFZFT/UwpSMvIXUk0uEUH BaxpnkogiJ4hfdGWtIuGibyRjdl2+9B27hufcRYntEXun0CdGXmxiNxQSWCcDdDJYO0F cTZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717596156; x=1718200956; h=to:references:message-id:date:cc:in-reply-to:from:subject :mime-version:content-transfer-encoding:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=gLKh/AK0cCAlaDiiAYYgR2lg0fhgWW804UNF5+SKj6U=; b=cug31yH5iXl7be2Ofj0Skz/eYQ0pED141gByCv0JJVEC7Oe5zi5/eu5v0PZOvVj14+ oYBs8reKRRuviBtstasScKLDFY1ruBuHSCRvJs8uItirQHHJADHfnksmcqGBpSLaGYnW dQs4lW7dQJoQi7Qd93dWqygYVjqCLIztlTbQH9QI8b4gjrU0uSWl2FMRAVGoputqBWZE Zif8Dj4t0KEQUj3ooZPDkLzRfslu8xljSd+UNh1CokrqrnCPS3tP7owE8XF7LhdEpOkG Q7gYN/l17CVo6Mv/hJYa+kbkU/aMCt8Xzk50a3H6pUmX31gAwDqpHA32DLB9tAPJdj1C IzZw== X-Forwarded-Encrypted: i=1; AJvYcCWxiwx3aoFeeHCPOfhEM3NUPClMCDbhT8QL4Y47xG78k9RB5vr4FczkDj/BWuw8PiNY0GMTGs3Xy632IJbKvicFWTay5bU= X-Gm-Message-State: AOJu0YwMpXM/nam2InYahj/TecYGcSCc/SGebKwfvrP+seNZLpVc24cR XKb1BN05IzCSWj+PhUDONeyTaFozrm5GWzS7FMP20uKxJz2eRzmr X-Google-Smtp-Source: AGHT+IGNKnBywrb1r5PEuFbLgvLT3OUMyM/D4IYE6aa0ArSQoQ94etrn0xBY6b91OzxP9igJtUxd/g== X-Received: by 2002:ae9:e407:0:b0:795:1838:c028 with SMTP id af79cd13be357-79523d412aamr249249385a.8.1717596155764; Wed, 05 Jun 2024 07:02:35 -0700 (PDT) Received: from smtpclient.apple ([198.30.180.100]) by smtp.gmail.com with ESMTPSA id af79cd13be357-79520da3aa9sm88280985a.134.2024.06.05.07.02.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Jun 2024 07:02:34 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-73ABB8D3-27E9-4237-8B5D-B17A0F535C2D Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: bug#71345: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil From: JD Smith <jdtsmith@HIDDEN> In-Reply-To: <86msnzk4pl.fsf@HIDDEN> Date: Wed, 5 Jun 2024 10:02:23 -0400 Message-Id: <64828D71-7A1D-4826-811A-A30E870358C7@HIDDEN> References: <86msnzk4pl.fsf@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> X-Mailer: iPhone Mail (21F90) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71345 Cc: 71345 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --Apple-Mail-73ABB8D3-27E9-4237-8B5D-B17A0F535C2D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >> In general, yes. In my case having the scope be per-buffer not per windo= w makes the most sense in terms of >> the functionality. >=20 > Given the feature of redisplay I just mentioned, you will actually get > a per-window functionality, at least as far as the position of point > is concerned. Not in my case, since I am discriminating between point in the selected wind= ow and other windows showing the same buffer, such that switching windows =3D= changing point. Since much of the work in my mode is not position-dependent= but depends on text content, updating face is the natural thing. =20 Thinking more about what makes font-lock =E2=80=9Cspecial=E2=80=9D as a jit-= lock backend, it is exactly this: font-lock claims exclusive ownership of `f= ace'. Solutions I can see: Make font-lock a good citizen by using its own alias for face.=20 Give other jit-lock backends which may alter face and potentially conflict w= ith font-lock the ability to specify to jit-lock =E2=80=9Cif you re-run font= lock on a region, re-run me too after that.=E2=80=9D= --Apple-Mail-73ABB8D3-27E9-4237-8B5D-B17A0F535C2D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><br><blockquote type=3D"ci= te"><blockquote type=3D"cite"><span></span><br></blockquote></blockquote><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><span>In general, yes. &nbs= p;In my case having the scope be per-buffer not per window makes the most se= nse in terms of</span><br></blockquote></blockquote><blockquote type=3D"cite= "><blockquote type=3D"cite"><span>the functionality.</span><br></blockquote>= </blockquote><blockquote type=3D"cite"><span></span><br></blockquote><blockq= uote type=3D"cite"><span>Given the feature of redisplay I just mentioned, yo= u will actually get</span><br></blockquote><blockquote type=3D"cite"><span>a= per-window functionality, at least as far as the position of point</span><b= r></blockquote><blockquote type=3D"cite"><span>is concerned.</span><br></blo= ckquote><br>Not in my case, since I am discriminating between point in the s= elected window and other windows showing the same buffer, such that switchin= g windows =3D changing point. Since much of the work in my mode is <i>not</i= > position-dependent but depends on text content, updating face is the natur= al thing. <br><br>Thinking more about what makes font-lock =E2=80=9Csp= ecial=E2=80=9D as a jit-lock backend, it is exactly this: font-lock claims e= xclusive ownership of `face'. Solutions I can see:</div><div dir=3D"lt= r"><ol><li>Make font-lock a good citizen by using its own alias for face.&nb= sp;</li><li>Give other jit-lock backends which may alter face and potentiall= y conflict with font-lock the ability to specify to jit-lock =E2=80=9Cif you= re-run font lock on a region, re-run me too after that.=E2=80=9D</li></ol><= /div></body></html>= --Apple-Mail-73ABB8D3-27E9-4237-8B5D-B17A0F535C2D--
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.Received: (at 71345) by debbugs.gnu.org; 5 Jun 2024 11:48:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 05 07:48:10 2024 Received: from localhost ([127.0.0.1]:55081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sEp7h-0001Zc-Nc for submit <at> debbugs.gnu.org; Wed, 05 Jun 2024 07:48:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sEp7c-0001Xs-Fo for 71345 <at> debbugs.gnu.org; Wed, 05 Jun 2024 07:48:04 -0400 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 <eliz@HIDDEN>) id 1sEokx-00020q-7D; Wed, 05 Jun 2024 07:24:39 -0400 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=t7PrBpgSnXg3ZooXkJxWj/DKfDrIC/iFTOGQRa4MU+Q=; b=UCYlDAaqsKfi 80ZJUGM4sYdsBZCBo8NTQNCzXuo4525sWb5bPNG3R8F9WoDUlskBSuHDnO3bQqntJlN+ohiaC7dP7 t6gyZM3Bq86ba80EPFFC/ofSP0WPRV5YDCN1JVrVsf41go5W+EexvF4dGl4D7QRrENIknlMFhP4Dm 32MwrMDWI4UH5AvU76uR24uU0hn4/Uu/7/k8dwWjoHE272HyZUTx5NwNRDtRyUaWDRS+8cWqeX2SX 2mNaoNagoXGIzaQpJ++e5/+IKlRiykPdwsvO1hfJ+dJ4Eh0DehaK60wS4ItWM092aCinfHZesE9TB cLkbtptK7XLw3XbKGo/KNQ==; Date: Wed, 05 Jun 2024 14:24:25 +0300 Message-Id: <86o78fk4ye.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwved9cl7ld.fsf-monnier+emacs@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#71345: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil References: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN> <jwvzfs29dyy.fsf-monnier+emacs@HIDDEN> <1F2B8726-7594-494F-AB9D-08C48B7BCC43@HIDDEN> <jwvtti9lcf0.fsf-monnier+emacs@HIDDEN> <DAC8D262-0862-45ED-BD3A-D95ED5FE9793@HIDDEN> <jwvmso0951x.fsf-monnier+emacs@HIDDEN> <798B70AF-69BD-479E-992E-5CE9B4924820@HIDDEN> <jwved9cl7ld.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71345 Cc: 71345 <at> debbugs.gnu.org, jdtsmith@HIDDEN, dmitry@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 71345 <at> debbugs.gnu.org, Dmitry Gutov <dmitry@HIDDEN> > Date: Tue, 04 Jun 2024 17:52:31 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > Because a given buffer can have several (window-)points, > position-dependent highlighting will ideally want to be added via > (window-specific) overlays rather than text-properties. Not sure I understand how this remark is relevant to the issue discussed here, but let me just point out that when redisplay starts working on a window, it temporarily moves point to the window-point position. So position-dependent highlighting will behave in each window according to its window-point, which I think is what's expected here?
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.Received: (at 71345) by debbugs.gnu.org; 5 Jun 2024 11:48:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 05 07:48:05 2024 Received: from localhost ([127.0.0.1]:55067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sEp7d-0001Yu-0o for submit <at> debbugs.gnu.org; Wed, 05 Jun 2024 07:48:05 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sEp7a-0001Xs-Gv for 71345 <at> debbugs.gnu.org; Wed, 05 Jun 2024 07:48:03 -0400 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 <eliz@HIDDEN>) id 1sEopv-00047R-2S; Wed, 05 Jun 2024 07:29:47 -0400 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=51DcnxF7M0SZjntRQ0EsDSH02//9+3bRHt3KT5x7phc=; b=F59rWa3c4kJl iHpVdfALwfFbAuUvzv9H+7W306kh6jQJxS7AtMsBag4s1LdQW18EEO4ag4+Bkd4zakXlZ/3nFGtUm /zSO5bNC1yRX+Y7DFSNpOZG1kqHReYwMPHhRu5zmX0iaa8Dg5e1zEA4L3hBqAvceabjDj3mHY8deg rY991Kn3QhBQEHrsDynynP/BRHQgHnwFeu7I5XbeMkLVJ1Z9/505j2aqPBxgWMw7iAXBh5Nc6goDp Z2y3FIn1GBvFreXjOwpeBQYfJ/VS3aU/vCjUMdOKatbXh5sCbRx5ie3jHrzvEiFY8MCfuSjlvr8RR sbW0ZpAFWsYfySK+MDxgoQ==; Date: Wed, 05 Jun 2024 14:29:42 +0300 Message-Id: <86msnzk4pl.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: JD Smith <jdtsmith@HIDDEN> In-Reply-To: <2D33113E-2F9F-44BD-8CB9-5BC8C0AED5AC@HIDDEN> (message from JD Smith on Tue, 4 Jun 2024 18:41:01 -0400) Subject: Re: bug#71345: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil References: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN> <jwvzfs29dyy.fsf-monnier+emacs@HIDDEN> <1F2B8726-7594-494F-AB9D-08C48B7BCC43@HIDDEN> <jwvtti9lcf0.fsf-monnier+emacs@HIDDEN> <DAC8D262-0862-45ED-BD3A-D95ED5FE9793@HIDDEN> <jwvmso0951x.fsf-monnier+emacs@HIDDEN> <798B70AF-69BD-479E-992E-5CE9B4924820@HIDDEN> <jwved9cl7ld.fsf-monnier+emacs@HIDDEN> <2D33113E-2F9F-44BD-8CB9-5BC8C0AED5AC@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71345 Cc: 71345 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 71345 <at> debbugs.gnu.org > From: JD Smith <jdtsmith@HIDDEN> > Date: Tue, 4 Jun 2024 18:41:01 -0400 > > (jit-lock-flush (min my-pd-old-beg (my-pd-new-beg-estimate)) > (max my-pd-old-end (my-pd-new-end-estimate)) > #'my-pd-backend) > > I don't need to estimate, I have treesitter to tell me precisely! Only if the parser successfully and correctly parses the buffer text. > Because a given buffer can have several (window-)points, > position-dependent highlighting will ideally want to be added via > (window-specific) overlays rather than text-properties. > > In general, yes. In my case having the scope be per-buffer not per window makes the most sense in terms of > the functionality. Given the feature of redisplay I just mentioned, you will actually get a per-window functionality, at least as far as the position of point is concerned.
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.Received: (at 71345) by debbugs.gnu.org; 4 Jun 2024 22:42:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 04 18:42:28 2024 Received: from localhost ([127.0.0.1]:58028 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sEcrL-0005bM-RD for submit <at> debbugs.gnu.org; Tue, 04 Jun 2024 18:42:28 -0400 Received: from mail-il1-f178.google.com ([209.85.166.178]:54474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jdtsmith@HIDDEN>) id 1sEcrJ-0005ay-LY for 71345 <at> debbugs.gnu.org; Tue, 04 Jun 2024 18:42:26 -0400 Received: by mail-il1-f178.google.com with SMTP id e9e14a558f8ab-374a817a13bso6546725ab.0 for <71345 <at> debbugs.gnu.org>; Tue, 04 Jun 2024 15:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717540866; x=1718145666; darn=debbugs.gnu.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=X0xIb9vAhgjOClAXRKprXREwSP0kdyZi+TI2M1YQKOo=; b=cEZDgCfK7HgdRi1F1LCJAWBKGvyCermf09OLHRHTTGo6cRk3GuX3jOBuSsRhfEzyFo OBWFLbc9oCzg1uxxtq6v0UoMEhus2/s6KBnZ5IN/LYR0Ebt3Sf4zwC3myXqdgufvdgal sYK4nK4hYrdQ0MKbZrTwxRe03HSQWuYMna4WXdsL+dAkbN+Hl+enWPBicfd9/ge6Jxat 4yN5FUfLYUqsid5Q3WRjrDTn/UCxx8sPS5Y0wV8xO93qHG9oTPY6acOOeBuJFAnCRTsA 4FqBshBPwmiHrN2ylAOjjDvE4oxn5BVXOmgY/5eC4LOKFu7eIM16/Nd/lCOtA2IpMYAE czrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717540866; x=1718145666; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=X0xIb9vAhgjOClAXRKprXREwSP0kdyZi+TI2M1YQKOo=; b=TyJ7/rY9wyZ5hPIuQ/kXfQ8BU3dQCipfxzzjDbgN0JOTQZOQW/gKez7WIThWx34n87 V3SX4s2zG8tdRM8c7/hXVbaR4fWg7wzqw5NEobAbQLM02kLgsFVT5BJB7rGa6XNIJkRc lnJBzvpJNbzrc/LSoUyNy1jzFdqtDZrDVREbbOBvBoa0q4a61CQinvSnLzAss3l+VrCc ZGfJkFs13KGzbob+9xq9PlUXqQZ75iwiGDhaM6hp2zf6lU3j0ZAhCcWeB4D/t0fpTnHK wTm9Sz2en+6w6EGcjEIl4AY8vI0pLb76VCcb44Vw7QrBwgjArGOx4sO3QU2Ge5KfvOhA brkQ== X-Gm-Message-State: AOJu0YzlNWKUrwLzIV3642onsByr7enGMXiP3pYV1Ta17SWx3JYJZ6/M wYvaH2xsT0wD0CQ6+oFXe8YdbZlDYR9yAoxIj1es6VP6eklk7fyewxrRdA== X-Google-Smtp-Source: AGHT+IFkO03AM82wbCwkLwFAXfVI2VmIfxzzlQk3UfGWu99h27hk38BjzvmLXVCL3o2r816fsu/xEg== X-Received: by 2002:a05:6e02:1685:b0:374:aba6:5102 with SMTP id e9e14a558f8ab-374b1ef300cmr7477515ab.9.1717540866037; Tue, 04 Jun 2024 15:41:06 -0700 (PDT) Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3748a2059d0sm23897325ab.50.2024.06.04.15.41.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2024 15:41:05 -0700 (PDT) From: JD Smith <jdtsmith@HIDDEN> Message-Id: <2D33113E-2F9F-44BD-8CB9-5BC8C0AED5AC@HIDDEN> Content-Type: multipart/alternative; boundary="Apple-Mail=_FBE09669-58EE-4D37-9844-F962BF85DC88" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil Date: Tue, 4 Jun 2024 18:41:01 -0400 In-Reply-To: <jwved9cl7ld.fsf-monnier+emacs@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> References: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN> <jwvzfs29dyy.fsf-monnier+emacs@HIDDEN> <1F2B8726-7594-494F-AB9D-08C48B7BCC43@HIDDEN> <jwvtti9lcf0.fsf-monnier+emacs@HIDDEN> <DAC8D262-0862-45ED-BD3A-D95ED5FE9793@HIDDEN> <jwvmso0951x.fsf-monnier+emacs@HIDDEN> <798B70AF-69BD-479E-992E-5CE9B4924820@HIDDEN> <jwved9cl7ld.fsf-monnier+emacs@HIDDEN> X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71345 Cc: 71345 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --Apple-Mail=_FBE09669-58EE-4D37-9844-F962BF85DC88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 4, 2024, at 5:52=E2=80=AFPM, Stefan Monnier = <monnier@HIDDEN> wrote: > Also, I think it's worth distinguishing the API from its = implementation. Fair point. =20 > or on the contrary if it's careful to do something like >=20 > (jit-lock-flush (min my-pd-old-beg (my-pd-new-beg-estimate)) > (max my-pd-old-end (my-pd-new-end-estimate)) > #'my-pd-backend) I don't need to estimate, I have treesitter to tell me precisely! >> Agreed that could be an issue. In practice keyword-based = fontification can >> lead to these same sorts of conflicts for non trivial FACE forms too. >> So backends would need to ensure the changes they are making in the = buffer >> are interoperable with the other likely backends (in particular = font-lock). >=20 > Because a given buffer can have several (window-)points, > position-dependent highlighting will ideally want to be added via > (window-specific) overlays rather than text-properties. In general, yes. In my case having the scope be per-buffer not per = window makes the most sense in terms of the functionality. >> This means other backends would still need to add to >> font-lock-extra-managed-props any unusual properties they will apply >> (or do the equivalent on their own during unfontify). >=20 > No: `font-lock-extra-managed-props` is a variable that belongs to > font-lock, not jit-lock. `font-lock` is *one* backend of jit-lock. I tend to associate font-lock and after-change in my head, but that's = backwards. Presumably after-change would clobber fontified and whatever = additional properties jit-lock uses to track its backends. So font-lock = has no special status. Perhaps I tend to think of it as special because = it touches so many locations in the buffer. > Other backends will have to use something else (and should use other > text-properties or should use overlays (or make sure font-lock is not > used), otherwise you'll get into conflicts with font-lock). Sometimes those are unavoidable, if you need to add some 'face on top of = what font-lock did. > If we want to allow backends that are not independent (e.g. your PD > highlighting that has to run after font-lock), then it make the API = more > complex, since `jit-lock-flush` on the font-lock backend would have to > know to also flush the PD backend I think it will be limiting to insist that all backends must be fully = orthogonal (i.e. can apply in any arbitrary order), so some sort of = priority or ordering system seems important. That said, mine only has = to run over font-lock because of multi-line strings/comments, and the = inability to set an independent 'face property. It's actually too bad font-lock doesn't itself use font-lock-face for = much, despite what the docs say [1]. Since it sets 'face directly, it = overrides any other property alias for 'face. If it instead used = 'font-lock-face (or left that to modes, and used some higher-ranked = 'font-lock-priority-face), other backends could use their own = 'alternate-face, and the order in char-property-alias-alist would set = the priority. Then it would be much easier to make face-using backends = more orthogonal. Regarding the priority of backends, while looking through jit-lock, I = was reminded of the completion-at-point-function's API, and the ability = to claim :exclusive access, halting calls to further functions on the = list. That's a strong power, but if used wisely, could be effective. > I think the code would loop over chunks of text where the property is > `eq` (e.g. using `next-single-property-change`). Then within each = such > chunk of text it would iterate over either all backends (and skip > those mentioned in the `already-fontified` text-property) or over the > `pending` property backends. That seems easy enough. But those may be small regions which are inefficient to work on. This = as you say is an implementation detail so probably not important yet. JD [1] =46rom `Search-based Fontification':=20 If it is =E2=80=98prepend=E2=80=99, the face specified by FACESPEC is = added to the beginning of the =E2=80=98font-lock-face=E2=80=99 property. = If it is =E2=80=98append=E2=80=99, the face is added to the end of the = =E2=80=98font-lock-face=E2=80=99 property. But I believe all font-lock keywords actually just set the 'face = property.= --Apple-Mail=_FBE09669-58EE-4D37-9844-F962BF85DC88 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;"><br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On Jun 4, 2024, at 5:52=E2=80=AFPM, Stefan Monnier = <monnier@HIDDEN> = wrote:</div><div></div></blockquote><br><blockquote = type=3D"cite"><div><div>Also, I think it's worth distinguishing the API = from its = implementation.<br></div></div></blockquote><div><br></div><div>Fair = point. </div><br><blockquote type=3D"cite"><div><div>or on the = contrary if it's careful to do something like<br><br> = (jit-lock-flush (min my-pd-old-beg = (my-pd-new-beg-estimate))<br> = &n= bsp; (max my-pd-old-end = (my-pd-new-end-estimate))<br> = &n= bsp; #'my-pd-backend)<br></div></div></= blockquote><div><br></div><div>I don't need to estimate, I have = treesitter to tell me <i>precisely</i>!</div><br><blockquote = type=3D"cite"><div><div><blockquote type=3D"cite">Agreed that could be = an issue. In practice keyword-based fontification can<br>lead to = these same sorts of conflicts for non trivial FACE forms too.<br>So = backends would need to ensure the changes they are making in the = buffer<br>are interoperable with the other likely backends (in = particular font-lock).<br></blockquote><br>Because a given buffer can = have several (window-)points,<br>position-dependent highlighting will = ideally want to be added via<br>(window-specific) overlays rather than = text-properties.<br></div></div></blockquote><div><br></div><div><div = style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">In general, = yes. In my case having the scope be per-buffer not per window = makes the most sense in terms of the = functionality.</div></div><br><blockquote = type=3D"cite"><div><div><blockquote type=3D"cite">This means other = backends would still need to add to<br>font-lock-extra-managed-props any = unusual properties they will apply<br>(or do the equivalent on their own = during unfontify).<br></blockquote><br>No: = `font-lock-extra-managed-props` is a variable that belongs = to<br>font-lock, not jit-lock. `font-lock` is *one* backend of = jit-lock.<br></div></div></blockquote><div><br></div><div>I tend to = associate font-lock and after-change in my head, but that's backwards. = Presumably after-change would clobber fontified and whatever = additional properties jit-lock uses to track its backends. So = font-lock has no special status. Perhaps I tend to think of it as = special because it touches so many locations in the = buffer.</div><br><blockquote type=3D"cite"><div><div>Other backends will = have to use something else (and should use other<br>text-properties or = should use overlays (or make sure font-lock is not<br>used), otherwise = you'll get into conflicts with = font-lock).<br></div></div></blockquote><div><br></div><div>Sometimes = those are unavoidable, if you need to add some 'face on top of what = font-lock did.</div><div><br></div><blockquote type=3D"cite"><div><div>If = we want to allow backends that are not independent (e.g. your = PD<br>highlighting that has to run after font-lock), then it make the = API more<br>complex, since `jit-lock-flush` on the font-lock backend = would have to<br>know to also flush the PD = backend<br></div></div></blockquote><div><br></div><div>I think it will = be limiting to insist that all backends must be fully orthogonal (i.e. = can apply in any arbitrary order), so some sort of priority or ordering = system seems important. That said, mine only has to run over = font-lock because of multi-line strings/comments, and the inability to = set an independent 'face property.</div><div><br></div><div><font = color=3D"#000000">It's actually too bad font-lock doesn't itself use = font-lock-face for much, despite what the docs say [1]. Since it = sets 'face directly, it overrides any other property alias for 'face. = If it instead used 'font-lock-face (or left that to modes, and = used some higher-ranked 'font-lock-priority-face), other backends could = use their own 'alternate-face, and the order = in </font>char-property-alias-alist would set the priority. = Then it would be much easier to make face-using backends more = orthogonal.</div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, = 0, 0);"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, = 0, 0);">Regarding the priority of backends, while looking through = jit-lock, I was reminded of the completion-at-point-function's API, and = the ability to claim :exclusive access, halting calls to further = functions on the list. That's a strong power, but if used wisely, = could be effective.</div><br><blockquote type=3D"cite"><div><div>I think = the code would loop over chunks of text where the property is<br>`eq` = (e.g. using `next-single-property-change`). Then within each = such<br>chunk of text it would iterate over either all backends (and = skip<br>those mentioned in the `already-fontified` text-property) or = over the<br>`pending` property backends. That seems easy = enough.<br></div></div></blockquote><div><br></div><div>But those may be = small regions which are inefficient to work on. This as you say is = an implementation detail so probably not important = yet.</div></div><div><br></div><div>JD</div><div><br></div><div>[1] =46rom= `Search-based Fontification': </div><blockquote style=3D"margin: 0 = 0 0 40px; border: none; padding: 0px;"><div><span style=3D"caret-color: = rgb(0, 0, 0); color: rgb(0, 0, 0);">If it is =E2=80=98prepend=E2=80=99, = the face specified by FACESPEC is</span><span style=3D"caret-color: = rgb(0, 0, 0); color: rgb(0, 0, 0);"> added to the beginning of the = =E2=80=98font-lock-face=E2=80=99 property. If it is =E2=80=98append=E2= =80=99, the face is added to the end of the =E2=80=98font-lock-face=E2=80=99= property.</span></div></blockquote><font color=3D"#000000"><span = style=3D"caret-color: rgb(0, 0, 0);">But I believe all font-lock = keywords actually just set the 'face = property.</span></font></body></html>= --Apple-Mail=_FBE09669-58EE-4D37-9844-F962BF85DC88--
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.
Received: (at 71345) by debbugs.gnu.org; 4 Jun 2024 22:02:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 04 18:02:31 2024
Received: from localhost ([127.0.0.1]:55018 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sEcEh-0003jf-99
for submit <at> debbugs.gnu.org; Tue, 04 Jun 2024 18:02:31 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:31576)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sEcEf-0003jH-HM
for 71345 <at> debbugs.gnu.org; Tue, 04 Jun 2024 18:02:30 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BF1BF444B3C;
Tue, 4 Jun 2024 17:52:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1717537952;
bh=gzNmDo+DNK66gb/LbUv/fUSf/AuXzLEeOheaBpRfvgg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=Tgj8s9cy8/cCBEWW9UJR7flfRczRTeFMyT35szlaAb03xi2urKgefZlEXRyziVMHr
jNQe2Mq5m10+yG4SrbPf4vsOIFaeQyByh4hUuEoderozy3wAElhu1PIU/VaMHf6vpa
H8L7MnbTt9dCn2AiW9uQRoRx8ZCNEvkyXLfDZpfarGBPEAFZwtP5eyzWyveHbyQAe4
D97QCmNT69awqpCNbN33jVYAauj39s7VmpIzKj54Q4mgwUs/es1/deBYCFENoK6In0
hod76CFu0Xx0oTDkftln58oYMfOKoBOeCqMWqT3XTeyNWge1hjsPnv4WGM0I/yDQj+
YRfRkd79Jy4LA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1A902444B3E;
Tue, 4 Jun 2024 17:52:32 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0CCB91205FB;
Tue, 4 Jun 2024 17:52:32 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: JD Smith <jdtsmith@HIDDEN>
Subject: Re: Feature: unleash font-lock's secret weapon; handle Qfontified =
non-nil
In-Reply-To: <798B70AF-69BD-479E-992E-5CE9B4924820@HIDDEN> (JD Smith's
message of "Tue, 4 Jun 2024 11:38:05 -0400")
Message-ID: <jwved9cl7ld.fsf-monnier+emacs@HIDDEN>
References: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN>
<jwvzfs29dyy.fsf-monnier+emacs@HIDDEN>
<1F2B8726-7594-494F-AB9D-08C48B7BCC43@HIDDEN>
<jwvtti9lcf0.fsf-monnier+emacs@HIDDEN>
<DAC8D262-0862-45ED-BD3A-D95ED5FE9793@HIDDEN>
<jwvmso0951x.fsf-monnier+emacs@HIDDEN>
<798B70AF-69BD-479E-992E-5CE9B4924820@HIDDEN>
Date: Tue, 04 Jun 2024 17:52:31 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.254 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71345
Cc: 71345 <at> debbugs.gnu.org, Dmitry Gutov <dmitry@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> In other words, for many cases there would in fact not be much
> property management work. This leads naturally to considering more
> complicated cases, with several additional fontification functions all
> interoperating. The property work will grow quickly (though I also
> outlined some ideas to keep it under control, which probably already
> occurred to you).
In theory, yes, but in practice it's not clear that's relevant.
Also, I think it's worth distinguishing the API from its implementation.
The question being whether the API is flexible enough for clients to
clearly express their needs while at the same time making it possible
for jit-lock to provide the functionality efficiently enough without
resorting to an oracle (even though the implementation at any given time
may suffer inefficiencies in some cases).
> As long as the additional property management costs are well below the
> savings you reap from not having repeated the unnecessary work, this would
> be a positive outcome. The 2-5ms I mention is the cost for me of running
> "one large backend" over one chunk =E2=80=94 namely font-lock-fontify-reg=
ion with
> treesitter backing. In my scenario of bar updates resulting from point
> motion, this represents purely wasted work. So if the additional "proper=
ty
> management" costs per chunk are, say, 100x below that, you are safely in
> "well worth it" territory.
That probably depends if your position-dependent backend does just
(jit-lock-flush (point-min) (point-max) #'my-pd-backend)
or on the contrary if it's careful to do something like
(jit-lock-flush (min my-pd-old-beg (my-pd-new-beg-estimate))
(max my-pd-old-end (my-pd-new-end-estimate))
#'my-pd-backend)
> Agreed that could be an issue. In practice keyword-based fontification c=
an
> lead to these same sorts of conflicts for non trivial FACE forms too.
> So backends would need to ensure the changes they are making in the buffer
> are interoperable with the other likely backends (in particular font-lock=
).
Because a given buffer can have several (window-)points,
position-dependent highlighting will ideally want to be added via
(window-specific) overlays rather than text-properties.
> This means other backends would still need to add to
> font-lock-extra-managed-props any unusual properties they will apply
> (or do the equivalent on their own during unfontify).
No: `font-lock-extra-managed-props` is a variable that belongs to
font-lock, not jit-lock. `font-lock` is *one* backend of jit-lock.
Other backends will have to use something else (and should use other
text-properties or should use overlays (or make sure font-lock is not
used), otherwise you'll get into conflicts with font-lock).
If we want to allow backends that are not independent (e.g. your PD
highlighting that has to run after font-lock), then it make the API more
complex, since `jit-lock-flush` on the font-lock backend would have to
know to also flush the PD backend.
> '(F) '(F A) '(F B) '(F C) '(F A B) '(F A C) '(F B C) '(F A B C)
> So jit-lock-fontify-now's job has gotten quite challenging, as it decides
> over what region to apply a particular backend, say A.
I think the code would loop over chunks of text where the property is
`eq` (e.g. using `next-single-property-change`). Then within each such
chunk of text it would iterate over either all backends (and skip
those mentioned in the `already-fontified` text-property) or over the
`pending` property backends. That seems easy enough.
Stefan
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 4 Jun 2024 15:38:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 04 11:38:41 2024 Received: from localhost ([127.0.0.1]:60885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sEWFE-0005em-H6 for submit <at> debbugs.gnu.org; Tue, 04 Jun 2024 11:38:41 -0400 Received: from lists.gnu.org ([209.51.188.17]:52132) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jdtsmith@HIDDEN>) id 1sEWFB-0005eU-Gc for submit <at> debbugs.gnu.org; Tue, 04 Jun 2024 11:38:38 -0400 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 <jdtsmith@HIDDEN>) id 1sEWEx-00080C-Ad for bug-gnu-emacs@HIDDEN; Tue, 04 Jun 2024 11:38:23 -0400 Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <jdtsmith@HIDDEN>) id 1sEWEt-0002mA-8Q for bug-gnu-emacs@HIDDEN; Tue, 04 Jun 2024 11:38:22 -0400 Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-6f8cd25ebd5so2896726a34.1 for <bug-gnu-emacs@HIDDEN>; Tue, 04 Jun 2024 08:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717515497; x=1718120297; darn=gnu.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=RFxdygIO1NIh85FSNp3Z78A4bBauKAgDag9oYG4Wstc=; b=g4UKxzSKoS72irMiBzVDOyDZWayueAtfDqOA/M8rAodhyTKaGHTVSgfx7xfqQR/FVH vtZ0RZI0gYK2a9F7+rGMvtRcJvyNuKryA5gMdMKiQmi2B+YmekcUmCVvFL0/0T0sfBqU hrpdlHs3FNuT5caMVoGO5E5CTMxWJ3Ad81gNxTjDHLnjNZZRflz68U6a6FsiGzmGglhT aQ+Waz0dRSfxS2sJUd++tSTs2qv0SIKLgj9q//BZ0TyVO5KUxbWEbUwLRIE/xrVi+vqo XlpAmfA8jzDMsPzx5EOZLDqvW4L9NZvRN3ePRpmrQ2gvcOja7OZn5cByNms5RtWgk3VZ 5Fag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717515497; x=1718120297; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RFxdygIO1NIh85FSNp3Z78A4bBauKAgDag9oYG4Wstc=; b=xJI9x/aZqmdFp1Y4VQ8wQwyEjnEYPa23uiuaZAnahCjNLmhKyHNZylTuwXXYrc4HT2 TUQli4dzOrd+uAetH7zwjDGdXV/XVr9skh5FSvY+lQr5YBBSUSoAXwqEBF1uUytKx9SY 06hJnjiztKWWZTEQRVl5xse5A7gRHki/R3RdAOIPNbZpx+gRAo3lgCNRb6hjw0qsPo3l E9LwoG0hPLVnJRpG5O2sKbfwn9SRLzGDon2dy8Wchb2WJtlEGSfWhiYOHkg6tmvVOEi4 CTst+rM0bWZ7ZGQy8DEq2q5dcBOQQ7MF3dBM9yldGwcEcrhB6uv4I6qrMq5qRu2Nbg23 hJPQ== X-Gm-Message-State: AOJu0YxnicV64xhNaieaQ3PBw+EKp2X6vk6z1wi76AzusEiB4BIe8wzl Qt0dOzYCzqc7Hr12s18UNQXm7qHH9FIy+GKiElXYwFgWRIyAXSuNvmNaZA== X-Google-Smtp-Source: AGHT+IFLYMF15LlvNqR0H965176upVpn0C/s61IgWBeoI08xsGzxf4i9wz65MyRYMN7d6+rk2VMA8w== X-Received: by 2002:a05:6830:1252:b0:6f9:3932:2ad4 with SMTP id 46e09a7af769-6f939322c4bmr2251948a34.38.1717515496884; Tue, 04 Jun 2024 08:38:16 -0700 (PDT) Received: from smtpclient.apple ([131.183.131.33]) by smtp.gmail.com with ESMTPSA id af79cd13be357-794f2f13ccdsm370753385a.44.2024.06.04.08.38.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2024 08:38:16 -0700 (PDT) From: JD Smith <jdtsmith@HIDDEN> Message-Id: <798B70AF-69BD-479E-992E-5CE9B4924820@HIDDEN> Content-Type: multipart/alternative; boundary="Apple-Mail=_6F099584-0520-4CCB-ACC9-249D01275136" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil Date: Tue, 4 Jun 2024 11:38:05 -0400 In-Reply-To: <jwvmso0951x.fsf-monnier+emacs@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> References: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN> <jwvzfs29dyy.fsf-monnier+emacs@HIDDEN> <1F2B8726-7594-494F-AB9D-08C48B7BCC43@HIDDEN> <jwvtti9lcf0.fsf-monnier+emacs@HIDDEN> <DAC8D262-0862-45ED-BD3A-D95ED5FE9793@HIDDEN> <jwvmso0951x.fsf-monnier+emacs@HIDDEN> X-Mailer: Apple Mail (2.3774.500.171.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::336; envelope-from=jdtsmith@HIDDEN; helo=mail-ot1-x336.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Dmitry Gutov <dmitry@HIDDEN>, bug-gnu-emacs@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) --Apple-Mail=_6F099584-0520-4CCB-ACC9-249D01275136 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 4, 2024, at 10:15=E2=80=AFAM, Stefan Monnier = <monnier@HIDDEN> wrote: >=20 >>>> That starts to sound like a lot of property slinging, which might = even >>>> dominate the work done. >>> Indeed, this amount of work could become significant. It's my main >>> worry, but I don't have a clear feel for how serious it would be >>> in practice. >> In my situation, the most likely scenario is that fontified=3Dnil is = noticed >> during redisplay when there is a fairly large stretch of = already-fontified >> property having the same value. So jit-lock-fontify-now will quickly = find >> a nice large chunk to call my FONTIFICATION-FUNCTION=3DF-F with. >> Since jit-lock-after-change will likely clear away already-fontified = and set >> fontified=3Dnil, a single additional F-F on top of jit-lock-function = will >> probably be very well handled. A good question is how it would scale = with >> more functions all operating in the same region. One idea is to rig = up >> a test file, do some fake jit-lock-flushing on it, and check = performance of >> just subtracting/searching/dividing the already-fontified property as = you >> add more (fake) F-F's. For me, jit-lock-fontify-now of a 2500 char = chunk >> in a heavy treesitter buffer is in the 2-5ms range. Individual F-F's = could >> be much lighter weight. >=20 > I must say that I can't follow you. I suspect we're not talking about > quite the same thing. Could you clarify what is the costs you imagine > could be significant? What you compare it to? Apologies for the lack of clarity. Here I was revisiting the notion = that "this amount of work could become significant." I was trying to = convey that the costs of i) applying the proposed = jit-lock-already-fontified property (with subtraction, as in your = original idea), and ii) parsing it into regions in jit-lock-fontify-now = might in fact be fairly minimal, for my situation. My situation =3D = font-lock-fontify-region + my-special-fontify-region. =20 In other words, for many cases there would in fact not be much property = management work. This leads naturally to considering more complicated = cases, with several additional fontification functions all = interoperating. The property work will grow quickly (though I also = outlined some ideas to keep it under control, which probably already = occurred to you). > You seem to be comparing "a single big jit-lock backend" vs "several > jit-lock backends", which is a completely different worry from mine. This is indeed the implicit comparison I'm making:=20 the current situation of a single big backend which redoes EVERYTHING as = potentially large regions are invalidated, with much of its work done = unnecessarily vs.=20 multiple backends used for more targeted & orthogonal updates, at the = cost of additional property management in jit-lock. As long as the additional property management costs are well below the = savings you reap from not having repeated the unnecessary work, this = would be a positive outcome. The 2-5ms I mention is the cost for me of = running "one large backend" over one chunk =E2=80=94 namely = font-lock-fontify-region with treesitter backing. In my scenario of bar = updates resulting from point motion, this represents purely wasted work. = So if the additional "property management" costs per chunk are, say, = 100x below that, you are safely in "well worth it" territory. > Splitting a backend into several backends comes with many more issues > (such as the issue of fighting over which one controls which = properties, > or removing internal dependencies such that none of them needs to look > at the properties set by the others, ...) but that seems largely > orthogonal to the question at hand: if you want to be able to refresh > the position-dependent highlighting separately from the rest of the > highlighting you need that position-dependent highlighting to be > independent anyway (e.g. you need to be able to remove it without > affecting the position-independent highlighting). Agreed that could be an issue. In practice keyword-based fontification = can lead to these same sorts of conflicts for non trivial FACE forms = too. So backends would need to ensure the changes they are making in = the buffer are interoperable with the other likely backends (in = particular font-lock). This also raises the question of what should happen after-change. In my = view, that should wipe the slate fully clean in the changed region. = This means other backends would still need to add to = font-lock-extra-managed-props any unusual properties they will apply (or = do the equivalent on their own during unfontify). And the order of = backend registration would be significant, with the last one having "the = final word". Context re-fontification is a special case of this: some = backends could ignore that, others would need to be re-run =E2=80=94 = something they'd have to decide by themselves.=20 >> But things like `text-property-any' will be quickly defeated by the >> combinatorics of a large F-F set. >=20 > `text-property-any` only tests `eq`ness so it works just as quickly = with > a property made up of a million-element list as with a property made = of > a boolean. >=20 > IOW, I again can't follow you. I was referring to the number of such lists, not the speed of testing = them. Imagine a scenario as follows: 4 different backends are all = operating over the same region =E2=80=94 F (for normal font-lock), A, B, = and C. As various invalidation events occur and backends call = jit-lock-flush, a given region of text may accumulate a patchwork of = already-fontified lists (here assuming F always wipes the slate clean as = it works, and therefore always appears on the already-fontified list): '(F) '(F A) '(F B) '(F C) '(F A B) '(F A C) '(F B C) '(F A B C) So jit-lock-fontify-now's job has gotten quite challenging, as it = decides over what region to apply a particular backend, say A. To know = whether it can skip A, it must either look inside all the lists to see = if there's an A, or it must look for lists `eq` to all possible = combinations which contain A. =20 It's possible you've already conceived of this and have a solution in = mind; apologies if so. My simple solution to this was to let the = property values themselves constitute the list of already-done/pending = backends. Then it's much easier to ask "is A already fontified = everywhere in this block"? >> So here's an idea. You could invert the logic, and have a set of >> `fontified-pending' properties which jit-lock-flush adds to as it = sets >> fontified=3Dnil, >=20 > Yes, of course, we could use the complement set. The distinct idea here was to map each backend to an individual = property, in place of the idea of a single property holding a list of = already-done or pending backends, with the aim of significantly reducing = property management costs. That's really just an implementation detail = though. =20 I think your concern of backend priority and the related issue of how = after-change and contextual refontification are handled is probably more = important to sort out.= --Apple-Mail=_6F099584-0520-4CCB-ACC9-249D01275136 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;"><br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On Jun 4, 2024, at 10:15=E2=80=AFAM, Stefan Monnier = <monnier@HIDDEN> wrote:</div><br = class=3D"Apple-interchange-newline"><div><meta = charset=3D"UTF-8"><blockquote type=3D"cite" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; orphans: auto; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><blockquote type=3D"cite"><blockquote = type=3D"cite">That starts to sound like a lot of property slinging, = which might even<br>dominate the work done.<br></blockquote>Indeed, this = amount of work could become significant. It's my main<br>worry, = but I don't have a clear feel for how serious it would be<br>in = practice.<br></blockquote>In my situation, the most likely scenario is = that fontified=3Dnil is noticed<br>during redisplay when there is a = fairly large stretch of already-fontified<br>property having the same = value. So jit-lock-fontify-now will quickly find<br>a nice large = chunk to call my FONTIFICATION-FUNCTION=3DF-F = with.</blockquote></div></blockquote><br><blockquote = type=3D"cite"><div><blockquote type=3D"cite" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; orphans: auto; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;">Since jit-lock-after-change will likely clear = away already-fontified and set<br>fontified=3Dnil, a single additional = F-F on top of jit-lock-function will<br>probably be very well handled. = A good question is how it would scale with<br>more functions all = operating in the same region. One idea is to rig up<br>a test = file, do some fake jit-lock-flushing on it, and check performance = of<br>just subtracting/searching/dividing the already-fontified property = as you<br>add more (fake) F-F's. For me, = jit-lock-fontify-now of a 2500 char chunk<br>in a heavy treesitter = buffer is in the 2-5ms range. Individual F-F's could<br>be much = lighter weight.<br></blockquote><br style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">I must = say that I can't follow you. I suspect we're not talking = about</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">quite the same thing. = Could you clarify what is the costs you imagine</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">could be significant? What you = compare it to?</span><br style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"></div></blockquote><div><br></div><div><div = style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Apologies for = the lack of clarity. Here I was revisiting the notion that "this = amount of work could become significant." I was trying to convey = that the costs of i) applying the proposed jit-lock-already-fontified = property (with subtraction, as in your original idea), and ii) parsing = it into regions in jit-lock-fontify-now might in fact be fairly minimal, = for my situation. My situation =3D font-lock-fontify-region + = my-special-fontify-region. </div><div style=3D"caret-color: rgb(0, = 0, 0); color: rgb(0, 0, 0);"><br></div><div style=3D"caret-color: rgb(0, = 0, 0); color: rgb(0, 0, 0);">In other words, for many cases there would = in fact <i>not</i> be much property management work. This leads = naturally to considering more complicated cases, with several additional = fontification functions all interoperating. The property work will = grow quickly (though I also outlined some ideas to keep it under = control, which probably already occurred to = you).</div></div><br><blockquote type=3D"cite"><div><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">You seem to be comparing "a single big = jit-lock backend" vs "several</span><br style=3D"caret-color: rgb(0, 0, = 0); font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline = !important;">jit-lock backends", which is a completely different worry = from mine.</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"></div></blockquote><div><br></div><div>This is indeed the = implicit comparison I'm making: </div><div><br></div><div><ol = class=3D"MailOutline"><li>the current situation of a single big backend = which redoes EVERYTHING as potentially large regions are invalidated, = with much of its work done unnecessarily vs. </li><li>multiple = backends used for more targeted & orthogonal updates, at the cost of = additional property management in = jit-lock.</li></ol></div><div><br></div>As long as the additional = property management costs are well below the savings you reap from not = having repeated the unnecessary work, this would be a positive outcome. = The 2-5ms I mention is the cost for me of running "one large = backend" over one chunk =E2=80=94 namely font-lock-fontify-region with = treesitter backing. In my scenario of bar updates resulting from = point motion, this represents purely wasted work. So if the = additional "property management" costs per chunk are, say, 100x below = that, you are safely in "well worth it" = territory.</div><div><br><blockquote type=3D"cite"><div><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">Splitting a backend into several backends = comes with many more issues</span><br style=3D"caret-color: rgb(0, 0, = 0); font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">(such = as the issue of fighting over which one controls which = properties,</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">or removing internal = dependencies such that none of them needs to look</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">at the properties set by the others, ...) = but that seems largely</span><br style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline = !important;">orthogonal to the question at hand: if you want to be able = to refresh</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">the position-dependent = highlighting separately from the rest of the</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">highlighting you need that = position-dependent highlighting to be</span><br style=3D"caret-color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = normal; font-variant-caps: normal; font-weight: 400; letter-spacing: = normal; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline = !important;">independent anyway (e.g. you need to be able to remove it = without</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">affecting the = position-independent highlighting).</span><br style=3D"caret-color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = normal; font-variant-caps: normal; font-weight: 400; letter-spacing: = normal; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"></div></blockquote><div><br></div><div>Agreed = that could be an issue. In practice keyword-based fontification = can lead to these same sorts of conflicts for non trivial FACE forms = too. So backends would need to ensure the changes they are making = in the buffer are interoperable with the other likely backends (in = particular font-lock).</div><div><br></div><div>This also raises the = question of what should happen after-change. In my view, that = should wipe the slate fully clean in the changed region. This = means other backends would still need to add = to font-lock-extra-managed-props any unusual properties they will = apply (or do the equivalent on their own during unfontify). And = the order of backend registration would be significant, with the last = one having "the final word". Context re-fontification is a special = case of this: some backends could ignore that, others would need to be = re-run =E2=80=94 something they'd have to decide by = themselves. </div><br><blockquote type=3D"cite"><div><blockquote = type=3D"cite" style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;">But things like `text-property-any' will be quickly defeated by = the<br>combinatorics of a large F-F set.<br></blockquote><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">`text-property-any` only tests `eq`ness so = it works just as quickly with</span><br style=3D"caret-color: rgb(0, 0, = 0); font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">a = property made up of a million-element list as with a property made = of</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">a boolean.</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">IOW, I again can't follow you.</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: = none;"></div></blockquote><div><br></div><div>I was referring to the = number of such lists, not the speed of testing them. Imagine a = scenario as follows: 4 different backends are all operating over the = same region =E2=80=94 F (for normal font-lock), A, B, and C. As = various invalidation events occur and backends call jit-lock-flush, a = given region of text may accumulate a patchwork of already-fontified = lists (here assuming F always wipes the slate clean as it works, and = therefore always appears on the already-fontified = list):</div><div><br></div></div><blockquote style=3D"margin: 0 0 0 = 40px; border: none; padding: 0px;"><div><div>'(F) '(F A) <span = style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">'(F = B) </span><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, = 0, 0);">'(F C) </span>'(F A B) '(F A C) '(F B C) '(F A = B C)</div></div></blockquote><div><br></div>So jit-lock-fontify-now's = job has gotten quite challenging, as it decides over what region to = apply a particular backend, say A. To know whether it can skip A, = it must either look inside all the lists to see if there's an A, or it = must look for lists `eq` to all possible combinations which contain A. = <div><br></div><div>It's possible you've already conceived of this = and have a solution in mind; apologies if so. My simple solution = to this was to let the property values themselves constitute the list of = already-done/pending backends. Then it's much easier to ask "is A = already fontified everywhere in this block"?<div><br><blockquote = type=3D"cite"><div><blockquote type=3D"cite" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; orphans: auto; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;">So here's an idea. You could invert the = logic, and have a set of<br>`fontified-pending' properties which = jit-lock-flush adds to as it sets<br>fontified=3Dnil,<br></blockquote><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">Yes, of course, we could use the complement = set.</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"></div></blockquote><div><br></div><div>The distinct idea here was = to map each backend to an individual property, in place of the idea of a = single property holding a list of already-done or pending backends, with = the aim of significantly reducing property management costs. = That's really just an implementation detail though. = </div><div><br></div><div>I think your concern of backend priority = and the related issue of how after-change and contextual refontification = are handled is probably more important to sort = out.</div></div></div></body></html>= --Apple-Mail=_6F099584-0520-4CCB-ACC9-249D01275136--
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 4 Jun 2024 14:16:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 04 10:16:30 2024
Received: from localhost ([127.0.0.1]:54793 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sEUxh-0007Nl-OA
for submit <at> debbugs.gnu.org; Tue, 04 Jun 2024 10:16:30 -0400
Received: from lists.gnu.org ([209.51.188.17]:53886)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sEUxe-0007NT-BW
for submit <at> debbugs.gnu.org; Tue, 04 Jun 2024 10:16:28 -0400
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 <monnier@HIDDEN>)
id 1sEUxO-0000PQ-5q
for bug-gnu-emacs@HIDDEN; Tue, 04 Jun 2024 10:16:12 -0400
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 <monnier@HIDDEN>)
id 1sEUxK-00060S-VL
for bug-gnu-emacs@HIDDEN; Tue, 04 Jun 2024 10:16:09 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5F966100064;
Tue, 4 Jun 2024 10:16:05 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1717510559;
bh=uopWs/2bP5I48sh/0SjvJesKP/kzYxlLCHrqKjWJF8A=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=G5Yl9l1PolH9NtLixag9/qOVErQJJo0FgAxV1U9cgOKi+e93MqqFQHyXfIwUTxOTG
CoCDZlUG3CtFHkijbvpRJaAVDqiuE6K7n/aVqNg8D0H9R2foUOP5nZCODijUjNyasM
hgA0pomSUOhFLsja4Ean+r0vpFty4HJQ26t4+yP9IqncRX3jIRsBa1PY2zR7fzvOOs
BfkV15iS5IIF9Pef4klkBiXWDxBe4MUMV1H8FDPBhF0cmzK0UIWDslCXovmk0IMr4S
hWBrVZXyQHzzfws20zcfj/WiiQkW7SozU99BlSXF/s1WC1W7uVSgKfvRFZKP+b97ib
T8O6CnecthfDA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B29CD100042;
Tue, 4 Jun 2024 10:15:59 -0400 (EDT)
Received: from alfajor (mtrlpq42zf4-70-26-189-134.dsl.bell.ca [70.26.189.134])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9DFA5120672;
Tue, 4 Jun 2024 10:15:59 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: JD Smith <jdtsmith@HIDDEN>
Subject: Re: Feature: unleash font-lock's secret weapon; handle Qfontified =
non-nil
In-Reply-To: <DAC8D262-0862-45ED-BD3A-D95ED5FE9793@HIDDEN> (JD Smith's
message of "Tue, 4 Jun 2024 08:08:40 -0400")
Message-ID: <jwvmso0951x.fsf-monnier+emacs@HIDDEN>
References: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN>
<jwvzfs29dyy.fsf-monnier+emacs@HIDDEN>
<1F2B8726-7594-494F-AB9D-08C48B7BCC43@HIDDEN>
<jwvtti9lcf0.fsf-monnier+emacs@HIDDEN>
<DAC8D262-0862-45ED-BD3A-D95ED5FE9793@HIDDEN>
Date: Tue, 04 Jun 2024 10:15:59 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
Received-SPF: pass client-ip=132.204.25.50;
envelope-from=monnier@HIDDEN; 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,
T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
Cc: Dmitry Gutov <dmitry@HIDDEN>, bug-gnu-emacs@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
>>> That starts to sound like a lot of property slinging, which might even
>>> dominate the work done.
>> Indeed, this amount of work could become significant. It's my main
>> worry, but I don't have a clear feel for how serious it would be
>> in practice.
> In my situation, the most likely scenario is that fontified=nil is noticed
> during redisplay when there is a fairly large stretch of already-fontified
> property having the same value. So jit-lock-fontify-now will quickly find
> a nice large chunk to call my FONTIFICATION-FUNCTION=F-F with.
>
> Since jit-lock-after-change will likely clear away already-fontified and set
> fontified=nil, a single additional F-F on top of jit-lock-function will
> probably be very well handled. A good question is how it would scale with
> more functions all operating in the same region. One idea is to rig up
> a test file, do some fake jit-lock-flushing on it, and check performance of
> just subtracting/searching/dividing the already-fontified property as you
> add more (fake) F-F's. For me, jit-lock-fontify-now of a 2500 char chunk
> in a heavy treesitter buffer is in the 2-5ms range. Individual F-F's could
> be much lighter weight.
I must say that I can't follow you. I suspect we're not talking about
quite the same thing. Could you clarify what is the costs you imagine
could be significant? What you compare it to?
You seem to be comparing "a single big jit-lock backend" vs "several
jit-lock backends", which is a completely different worry from mine.
Splitting a backend into several backends comes with many more issues
(such as the issue of fighting over which one controls which properties,
or removing internal dependencies such that none of them needs to look
at the properties set by the others, ...) but that seems largely
orthogonal to the question at hand: if you want to be able to refresh
the position-dependent highlighting separately from the rest of the
highlighting you need that position-dependent highlighting to be
independent anyway (e.g. you need to be able to remove it without
affecting the position-independent highlighting).
> But things like `text-property-any' will be quickly defeated by the
> combinatorics of a large F-F set.
`text-property-any` only tests `eq`ness so it works just as quickly with
a property made up of a million-element list as with a property made of
a boolean.
IOW, I again can't follow you.
> So here's an idea. You could invert the logic, and have a set of
> `fontified-pending' properties which jit-lock-flush adds to as it sets
> fontified=nil,
Yes, of course, we could use the complement set.
Stefan
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 4 Jun 2024 12:09:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 04 08:09:12 2024 Received: from localhost ([127.0.0.1]:44015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sESyV-0006ir-ND for submit <at> debbugs.gnu.org; Tue, 04 Jun 2024 08:09:12 -0400 Received: from lists.gnu.org ([209.51.188.17]:40068) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jdtsmith@HIDDEN>) id 1sESyT-0006ii-P4 for submit <at> debbugs.gnu.org; Tue, 04 Jun 2024 08:09:10 -0400 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 <jdtsmith@HIDDEN>) id 1sESyG-00029f-2M for bug-gnu-emacs@HIDDEN; Tue, 04 Jun 2024 08:08:56 -0400 Received: from mail-il1-x133.google.com ([2607:f8b0:4864:20::133]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <jdtsmith@HIDDEN>) id 1sESyE-0005Wm-1q for bug-gnu-emacs@HIDDEN; Tue, 04 Jun 2024 08:08:55 -0400 Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-37491216a2bso14633675ab.1 for <bug-gnu-emacs@HIDDEN>; Tue, 04 Jun 2024 05:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717502933; x=1718107733; darn=gnu.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=arw7RADAmRYuMEsif4//EgrSbIwd5Z5A2kz4Mk28+so=; b=ntoEByyvemFllVGfDYRVHANlSMhO8mFs/gLo1WHNYLqAaf88GfI/G3DDsFJwysR2J6 rlEpCJ4OYAxuYzc/kf9iZHv1hpXNEGKOq2U6sDVhS/eWrYWIWeMK1qkch2w6HmxAZuxz ddLVYrkq+bWz/dY0nhVeYv855lRkAaCreuEKu6i7CrjuNB68sIyyQALkF70verZbZhXA FcQu5rJqNOBcuF42bEoQHSSr2TTS4kpXvDfeSgJ+DvRGxzeY7zx17080Zaly+pk9WlLq WzgRvWlP2YaZYX7foMsNQE8LLlwOWP0+SXGEcx/d2rVxNT/cQgtf1dEV3qbIMN3IQxdG ZwMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717502933; x=1718107733; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=arw7RADAmRYuMEsif4//EgrSbIwd5Z5A2kz4Mk28+so=; b=o+Dj5JhVSMd1N2aEut+QnE81TUIU5jcAlXiHjMZe3rIG6JRApzAXwk7rDIISSGUwSS i7RuCT7j2DdmP98ZPpcW3jIQB0gTthzyoRjlMm3D8e7rkIphFlWv2siNLiOhX4S/Axm/ PMt3cOzwKezGMa+NbknCk3TciFFVuzcs9/43rj8BNVEGZ+t5xXH53KmYlFJehSDXvIQL nDUVrtedoTkHqgt6NfzlyyIauvgoKQnaZqKwEpnQ8Q5mJUdPJyJkbvgugFoVZntAOp0M b5yN0bgI73kPIkPmt/36ZI6z8FNu6gp4rO+rSzzfpyjWFyGVayPIGT4yMvAnTAl9+Vrw B3Kw== X-Gm-Message-State: AOJu0YzXXWoUCgFdefCHiOVV0pKCbh7IjB0v5th9JAThzVD6KpIgOL4A VtfkcOdi0Vj/xN9ISosUaNdEV5y8XX+j8f+//Ph26p6hFrgkuM3f0rPppQ== X-Google-Smtp-Source: AGHT+IGn1c2ndvEhHvg1YOpoNPB5tOYcMt/U9bLHUd+P9GOZPUMraN2Ss2akUbQDWQAj4uOv999pOQ== X-Received: by 2002:a05:6e02:2185:b0:374:70ed:d741 with SMTP id e9e14a558f8ab-3748b96e54amr125917185ab.1.1717502932358; Tue, 04 Jun 2024 05:08:52 -0700 (PDT) Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3748a2052aesm22025825ab.40.2024.06.04.05.08.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2024 05:08:51 -0700 (PDT) From: JD Smith <jdtsmith@HIDDEN> Message-Id: <DAC8D262-0862-45ED-BD3A-D95ED5FE9793@HIDDEN> Content-Type: multipart/alternative; boundary="Apple-Mail=_31C5F096-BF60-490E-9693-F2184FE27400" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil Date: Tue, 4 Jun 2024 08:08:40 -0400 In-Reply-To: <jwvtti9lcf0.fsf-monnier+emacs@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> References: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN> <jwvzfs29dyy.fsf-monnier+emacs@HIDDEN> <1F2B8726-7594-494F-AB9D-08C48B7BCC43@HIDDEN> <jwvtti9lcf0.fsf-monnier+emacs@HIDDEN> X-Mailer: Apple Mail (2.3774.500.171.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::133; envelope-from=jdtsmith@HIDDEN; helo=mail-il1-x133.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Dmitry Gutov <dmitry@HIDDEN>, bug-gnu-emacs@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) --Apple-Mail=_31C5F096-BF60-490E-9693-F2184FE27400 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 >> That starts to sound like a lot of property slinging, which might = even >> dominate the work done. >=20 > Indeed, this amount of work could become significant. It's my main > worry, but I don't have a clear feel for how serious it would be > in practice. In my situation, the most likely scenario is that fontified=3Dnil is = noticed during redisplay when there is a fairly large stretch of = already-fontified property having the same value. So = jit-lock-fontify-now will quickly find a nice large chunk to call my = FONTIFICATION-FUNCTION=3DF-F with. Since jit-lock-after-change will likely clear away already-fontified and = set fontified=3Dnil, a single additional F-F on top of jit-lock-function = will probably be very well handled. A good question is how it would = scale with more functions all operating in the same region. One idea is = to rig up a test file, do some fake jit-lock-flushing on it, and check = performance of just subtracting/searching/dividing the already-fontified = property as you add more (fake) F-F's. For me, jit-lock-fontify-now of = a 2500 char chunk in a heavy treesitter buffer is in the 2-5ms range. = Individual F-F's could be much lighter weight. > We could try and unify `fontified` and `jit-lock-already-fontified` by > having a `fontified-done-value` variable and making the redisplay call > jit-lock whenever `fontified` has a value that's not-eq from > `fontified-done-value`. >=20 > So jit-lock would set `fontified-done-value` to the list of backends. Nice idea. Since redisplay just directs jit-lock to a "starting = position", it would be free to update however much buffer text it wants. = To overcome the issue of "many small domains", jit-lock could cheat, = for example checking if ANY chars in the next block need a particular = F-F, and running it on the full block if so. That's already implicitly = how jit-lock works now if I understand correctly. But things like = `text-property-any' will be quickly defeated by the combinatorics of a = large F-F set. Also, an advantage of keeping the fontified=3Dnil = semantics is that changes to jit-lock could be back-ported to earlier = Emacs versions. So here's an idea. You could invert the logic, and have a set of = `fontified-pending' properties which jit-lock-flush adds to as it sets = fontified=3Dnil, maintaining one property symbol for each F-F (e.g. = fontified-pending-N). Then jit-lock-flush's only job is to select and = apply one such property over the region, and fontify-now can use a = simple and very fast `text-property-any' as it loops through the list of = F-F's, and a final `remove-list-of-text-properties' to strip them all = away. For the convenience of jit-lock-after-change, setting a "single = property to rule them all" (fontified-pending=3Dt) directs jit-lock to = run all the F-F's, there. fontify-now could check for that first, then = only bother to look for the individual (-N) properties if it is not set. = Is there code out there that sets fontified=3Dnil on its own or is that = an internal detail of jit-lock? >> I imagine that the functions may also need a way to opt-out of = "deferred >> contextual refontification", for example if they add some other >> properties/overlays orthogonal to face. >=20 > `jit-lock.el` already has that info (it's the second arg to > `jit-lock-register`), but it currently doesn't keep track of it > individually for each backend. Great, so this information could be put into action using one of these = approaches. --Apple-Mail=_31C5F096-BF60-490E-9693-F2184FE27400 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dus-ascii"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: = after-white-space;"><br><div><blockquote = type=3D"cite"><div><div><br><blockquote type=3D"cite">That starts to = sound like a lot of property slinging, which might even<br>dominate the = work done.<br></blockquote><br>Indeed, this amount of work could become = significant. It's my main<br>worry, but I don't have a clear feel = for how serious it would be<br>in = practice.<br></div></div></blockquote><div><br></div><div>In my = situation, the most likely scenario is that fontified=3Dnil is noticed = during redisplay when there is a fairly large stretch of = already-fontified property having the same value. So <span = style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, = 0);">jit-lock-fontify-now will quickly find a nice large chunk to call = my </span><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, = 0, 0);">FONTIFICATION-FUNCTION=3D</span><span style=3D"caret-color: = rgb(0, 0, 0); color: rgb(0, 0, 0);">F-F = with.</span></div><div><br></div><div>Since jit-lock-after-change will = likely clear away<span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, = 0, 0);"> already-fontified</span> and set fontified=3Dnil, a = single additional F-F on top of jit-lock-function will probably be very = well handled. A good question is how it would scale with more = functions all operating in the same region. One idea is to rig up = a test file, do some fake jit-lock-flushing on it, and check performance = of just subtracting/searching/dividing the already-fontified property as = you add more (fake) F-F's. For me, jit-lock-fontify-now of a 2500 = char chunk in a heavy treesitter buffer is in the 2-5ms range. = Individual F-F's could be much lighter = weight.</div><br><blockquote type=3D"cite"><div><div>We could try and = unify `fontified` and `jit-lock-already-fontified` by<br>having a = `fontified-done-value` variable and making the redisplay = call<br>jit-lock whenever `fontified` has a value that's not-eq = from<br>`fontified-done-value`.<br><br>So jit-lock would set = `fontified-done-value` to the list of = backends.<br></div></div></blockquote><div><br></div><div>Nice idea. = Since redisplay just directs jit-lock to a "starting position", it = would be free to update however much buffer text it wants. To = overcome the issue of "many small domains", jit-lock could cheat, for = example checking if ANY chars in the next block need a particular F-F, = and running it on the full block if so. <span style=3D"caret-color: = rgb(0, 0, 0); color: rgb(0, 0, 0);">That's already implicitly how = jit-lock works now if I understand correctly. </span>But things = like `text-property-any' will be quickly defeated by the combinatorics = of a large F-F set. Also, an advantage of keeping the = fontified=3Dnil semantics is that changes to jit-lock could be = back-ported to earlier Emacs versions.</div><div><br></div><div>So = here's an idea. You could invert the logic, and have a set of = `fontified-pending' properties which jit-lock-flush adds to as it sets = fontified=3Dnil, maintaining one property symbol for each F-F (e.g. = fontified-pending-N). Then jit-lock-flush's only job is to select = and apply one such property over the region, and fontify-now can use a = simple and very fast `text-property-any' as it loops through the list of = F-F's, and a final `<span style=3D"caret-color: rgb(0, 0, 0); color: = rgb(0, 0, 0);">remove-list-of-text-properties' to strip them all away. = For the convenience of </span><font color=3D"#000000"><span = style=3D"caret-color: rgb(0, 0, 0);">jit-lock-after-change, setting a = "single property to rule them all" (fontified-pending=3Dt) directs = jit-lock to run </span></font><i style=3D"caret-color: rgb(0, 0, 0); = color: rgb(0, 0, 0);">all</i><font color=3D"#000000"> the F-F's, there. = fontify-now could check for that first, then only bother to look = for the individual (-N) properties if it is not set. Is there code = out there that sets fontified=3Dnil on its own or is that an internal = detail of jit-lock?</font></div><div><br></div><blockquote = type=3D"cite"><div><div><blockquote type=3D"cite">I imagine that the = functions may also need a way to opt-out of "deferred<br>contextual = refontification", for example if they add some = other<br>properties/overlays orthogonal to = face.<br></blockquote><br>`jit-lock.el` already has that info (it's the = second arg to<br>`jit-lock-register`), but it currently doesn't keep = track of it<br>individually for each = backend.<br></div></div></blockquote></div><br><div>Great, so this = information could be put into action using one of these = approaches.</div><div><br></div></body></html>= --Apple-Mail=_31C5F096-BF60-490E-9693-F2184FE27400--
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 4 Jun 2024 01:45:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 03 21:45:03 2024
Received: from localhost ([127.0.0.1]:56028 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sEJEU-0002oq-UU
for submit <at> debbugs.gnu.org; Mon, 03 Jun 2024 21:45:03 -0400
Received: from lists.gnu.org ([209.51.188.17]:34170)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sEJET-0002oI-Cj
for submit <at> debbugs.gnu.org; Mon, 03 Jun 2024 21:45:02 -0400
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 <monnier@HIDDEN>)
id 1sEJEF-0002N7-SY
for bug-gnu-emacs@HIDDEN; Mon, 03 Jun 2024 21:44:48 -0400
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 <monnier@HIDDEN>)
id 1sEJEE-0007ky-56
for bug-gnu-emacs@HIDDEN; Mon, 03 Jun 2024 21:44:47 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 59112444AD4;
Mon, 3 Jun 2024 21:44:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1717465477;
bh=IWpA4kMrmDk/Xhwe3b+R/ZGANlwSaVoYhzPfAGXpYqY=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=V3tFj/UXPSaqidWQKzIBJWXshdDkHbJaDncc6lMVmdbfHjeyG4muts+JatKOTHqlA
G8Lc2womnV/3Dbi8TaS3+Br148AybkbQXn146O56dNrbgzhbeCzseVuH6XOldztXXq
NIEEj8atMnL5tVmTTsD92p21MWbN+1dnWhj5J0/buvZabnvBKoWsP80mt672knH8fU
TFXRTgAdJcAv2+hk2NvL/27R/5AbMvQPSkpj9W6RIV1FHgQBrC4z/i16Mx4YIb0URj
1uNT1r5QWtc/efTdB2uas67vk3pDS8ebbjT+wAck4qxDX+cKCgpqbKgjmAW7neEBMC
NpXOR6bZAIhQg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CA40F444ACF;
Mon, 3 Jun 2024 21:44:37 -0400 (EDT)
Received: from pastel (unknown [24.140.236.196])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6281F120656;
Mon, 3 Jun 2024 21:44:37 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: JD Smith <jdtsmith@HIDDEN>
Subject: Re: Feature: unleash font-lock's secret weapon; handle Qfontified =
non-nil
In-Reply-To: <1F2B8726-7594-494F-AB9D-08C48B7BCC43@HIDDEN> (JD Smith's
message of "Mon, 3 Jun 2024 17:14:49 -0400")
Message-ID: <jwvtti9lcf0.fsf-monnier+emacs@HIDDEN>
References: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN>
<jwvzfs29dyy.fsf-monnier+emacs@HIDDEN>
<1F2B8726-7594-494F-AB9D-08C48B7BCC43@HIDDEN>
Date: Mon, 03 Jun 2024 21:44:36 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.126 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
Received-SPF: pass client-ip=132.204.25.50;
envelope-from=monnier@HIDDEN; 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,
T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
Cc: Dmitry Gutov <dmitry@HIDDEN>, bug-gnu-emacs@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
> Thanks. Very interesting approach, recycling the existing Qfontified
> handler. I wonder though, if you have several different unrelated functions
> calling `jit-lock-flush' with different FONTIFICATION-FUNCTION's prior to
> jit-lock-fontify-now running on a region, won't they step on each other?
Not if `jit-lock.el` handles it correctly, no.
> I.e it seems that you would need to look for existing
> jit-lock-already-fontified+fontified=nil properties over the region
> mentioned in jit-lock-flush and subtract the passed FONTIFICATION-FUNCTION
> from the various values already found there.
Yes, of course.
> Of course you'd also need to handle the case where you "subtract it
> all the way to nil".
I don't think you'd need to do anything special for this case.
> That starts to sound like a lot of property slinging, which might even
> dominate the work done.
Indeed, this amount of work could become significant. It's my main
worry, but I don't have a clear feel for how serious it would be
in practice.
We could try and unify `fontified` and `jit-lock-already-fontified` by
having a `fontified-done-value` variable and making the redisplay call
jit-lock whenever `fontified` has a value that's not-eq from
`fontified-done-value`.
So jit-lock would set `fontified-done-value` to the list of backends.
> I imagine that the functions may also need a way to opt-out of "deferred
> contextual refontification", for example if they add some other
> properties/overlays orthogonal to face.
`jit-lock.el` already has that info (it's the second arg to
`jit-lock-register`), but it currently doesn't keep track of it
individually for each backend.
Stefan
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 3 Jun 2024 21:15:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 03 17:15:24 2024 Received: from localhost ([127.0.0.1]:55859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sEF1X-00037Z-RE for submit <at> debbugs.gnu.org; Mon, 03 Jun 2024 17:15:24 -0400 Received: from lists.gnu.org ([209.51.188.17]:36020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jdtsmith@HIDDEN>) id 1sEF1T-00037P-56 for submit <at> debbugs.gnu.org; Mon, 03 Jun 2024 17:15:22 -0400 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 <jdtsmith@HIDDEN>) id 1sEF1F-0005FM-PS for bug-gnu-emacs@HIDDEN; Mon, 03 Jun 2024 17:15:05 -0400 Received: from mail-qt1-x82f.google.com ([2607:f8b0:4864:20::82f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <jdtsmith@HIDDEN>) id 1sEF1D-0002iG-41 for bug-gnu-emacs@HIDDEN; Mon, 03 Jun 2024 17:15:05 -0400 Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-43fb45079e4so1330931cf.2 for <bug-gnu-emacs@HIDDEN>; Mon, 03 Jun 2024 14:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717449302; x=1718054102; darn=gnu.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=42VT38PfX1D4R6g7a9J5XE5WqE2QjujL/0JyyTnOtbc=; b=KgtDxIWkIrtBgfTidtc2toRuyi0eUDa1IBS5+BT7OM6v9lV52Ak7ZUkby2viNxZhMT 3HY/hwUufNigkylHDlZTn3e4dPBkda5eq+7JYkEPUDkblBTv8eqzmmZ03Js/BcYyowdK O11IWu1q1WqQ4iLEHLWDyYphowUHsOgk+LPDxgOuEx/DvJgGYLr5JHzUB4XN6r35Lk4O GW4rNCmNX4maaR5pYBaVd+Aa8myDlyL9alPucaO0drR0SvvDZErr3PTPZnO0C7ykLf7o gn7U7rL85z45H86tiKjRMLeWhbhtVjKYEO5/+Z7EYT7zFiVmW7QkaYtdbDKLnYwb0VrR 9s3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717449302; x=1718054102; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=42VT38PfX1D4R6g7a9J5XE5WqE2QjujL/0JyyTnOtbc=; b=VwkuRe1s++G5Pmh19JcGdpOU71s0xQyS7/Ti2Fqa5tUKS82r7NGj4ixZfBJehPvC+f Nlir2kPbSOPHlAHgws55QQ3UVa380sDVVACDZqhGrYwOp6+KhfhHdoC5xW8hhLjIZv8J M2LG/COxthrWiFjmizMczd13V3dtIRIeW0RkN/ugaR6DKh8/Xc+t5+TqPJ6GQGxbDB/u /VZs2BWwabfSGmRs0Sqp3CU2GzRV+Z6E6FEQS2jZtjfomLUYOUDydV4litN3ARpJOqwN kDeqgvJvVVHuAMugazCEfmDPKQU/TklfLABxGERP9BaAh/6rkpwXmzyQYSdKSTZcMX10 bbdg== X-Gm-Message-State: AOJu0YzCzUft6cx3effe1YwidZJ1MBDYxrPxRUWJtQr3D2xa5Vzd7dMr uL9FM0tG8rO9V8BmAiEVwD1pc984DgY2v5gSyW+j7KrAnFfcEgc7 X-Google-Smtp-Source: AGHT+IFX9BYiL+c9eJi3HzeEOwXh2gR+L5EE8hCJToo2dImJVP9+ccrmQLw9XNCbQScChpRgCt7IfQ== X-Received: by 2002:ac8:5ac7:0:b0:43b:7be:15a1 with SMTP id d75a77b69052e-43ff5236bcemr110684961cf.12.1717449301426; Mon, 03 Jun 2024 14:15:01 -0700 (PDT) Received: from smtpclient.apple ([131.183.131.33]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4400810b022sm23733841cf.93.2024.06.03.14.15.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jun 2024 14:15:00 -0700 (PDT) From: JD Smith <jdtsmith@HIDDEN> Message-Id: <1F2B8726-7594-494F-AB9D-08C48B7BCC43@HIDDEN> Content-Type: multipart/alternative; boundary="Apple-Mail=_B12DECD9-6ADA-455A-AE8B-B1F55A046ABF" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil Date: Mon, 3 Jun 2024 17:14:49 -0400 In-Reply-To: <jwvzfs29dyy.fsf-monnier+emacs@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> References: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN> <jwvzfs29dyy.fsf-monnier+emacs@HIDDEN> X-Mailer: Apple Mail (2.3774.500.171.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::82f; envelope-from=jdtsmith@HIDDEN; helo=mail-qt1-x82f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Dmitry Gutov <dmitry@HIDDEN>, bug-gnu-emacs@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) --Apple-Mail=_B12DECD9-6ADA-455A-AE8B-B1F55A046ABF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 3, 2024, at 12:56=E2=80=AFPM, Stefan Monnier = <monnier@HIDDEN> wrote: >=20 >> In my particular case, I've been trying for several months to achieve >> a scheme for position-dependent additional fontification based on = treesitter >> scope: think font-lock, but respondent not just to the contents of = the >> buffer, but also the location of point within it. My particular = application >> is drawing treesitter scope-aware indentation bars. There are many = other >> applications you could envision, including many discussed here >> (e.g. bug#22404). >=20 > I've been meaning to add support for that to jit-lock. > Here's the design I have in mind: >=20 > =46rom the outside, only one change, i.e. a new function >=20 > (jit-lock-flush BEG END FONTIFICATION-FUNCTION) >=20 > where FONTIFICATION-FUNCTION is the exact same function that was = passed > to `jit-lock-register` (and is thus used as a kind of identifier of = the > corresponding backend). >=20 > So in your case, when the position-dependent highlighting needs to be > updated, you'd request it by calling `jit-lock-flush`. >=20 > The way it would be implemented inside `jit-lock.el` is that > `jit-lock-flush` would set `fontified` to nil over that whole region, > but before that it would scan the region for those places where > `fontified` is non-nil, and set the `jit-lock-already-fontified` = property > to the list of currently active backends (minus = FONTIFICATION-FUNCTION), > so as to remember that while this region does require jit-lock action > those backends don't need to be called. Thanks. Very interesting approach, recycling the existing Qfontified = handler. I wonder though, if you have several different unrelated = functions calling `jit-lock-flush' with different = FONTIFICATION-FUNCTION's prior to jit-lock-fontify-now running on a = region, won't they step on each other? I.e it seems that you would need = to look for existing jit-lock-already-fontified+fontified=3Dnil = properties over the region mentioned in jit-lock-flush and subtract the = passed FONTIFICATION-FUNCTION from the various values already found = there. Of course you'd also need to handle the case where you "subtract = it all the way to nil". That starts to sound like a lot of property = slinging, which might even dominate the work done. I don't guess there = is a fast hidden (remove-from-text-property-lists beg end property val-to-remove) You could end also up with a quilted patchwork of different levels of = the already-fontified property before you clear them, which might make = jit-lock-fontify-now's job harder. Although for my particular case I = doubt this will be a problem: jit-lock-after-change will set fontified=3Dnil (and btw, will probably = also need to clear the already-fontified property over the affected = change region). My tree-sitter based code, upon edits and position-based scope changes, = will use jit-lock-flush to add already-fontified properties to the = affected locations where fontified=3Dt (if any). I imagine that the functions may also need a way to opt-out of "deferred = contextual refontification", for example if they add some other = properties/overlays orthogonal to face. Perhaps this could be done by = having jit-lock-context-fontify setup the "rest of the buffer" with = already-fontified =3D jit-lock-no-context-functions =E2=80=94 an = optional list of FONTIFICATION-FUNCTION's that don't require contextual = refontification.= --Apple-Mail=_B12DECD9-6ADA-455A-AE8B-B1F55A046ABF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;"><br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On Jun 3, 2024, at 12:56=E2=80=AFPM, Stefan Monnier = <monnier@HIDDEN> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div><blockquote type=3D"cite">In= my particular case, I've been trying for several months to achieve<br>a = scheme for position-dependent additional fontification based on = treesitter<br>scope: think font-lock, but respondent not just to the = contents of the<br>buffer, but also the location of point within it. = My particular application<br>is drawing treesitter scope-aware = indentation bars. There are many other<br>applications you could = envision, including many discussed here<br>(e.g. bug#22404). = <br></blockquote><br>I've been meaning to add support for that to = jit-lock.<br>Here's the design I have in mind:<br><br>=46rom the = outside, only one change, i.e. a new function<br><br> = (jit-lock-flush BEG END = FONTIFICATION-FUNCTION)<br><br>where FONTIFICATION-FUNCTION is the exact = same function that was passed<br>to `jit-lock-register` (and is thus = used as a kind of identifier of the<br>corresponding backend).<br><br>So = in your case, when the position-dependent highlighting needs to = be<br>updated, you'd request it by calling `jit-lock-flush`.<br><br>The = way it would be implemented inside `jit-lock.el` is = that<br>`jit-lock-flush` would set `fontified` to nil over that whole = region,<br>but before that it would scan the region for those places = where<br>`fontified` is non-nil, and set the = `jit-lock-already-fontified` property<br>to the list of currently active = backends (minus FONTIFICATION-FUNCTION),<br>so as to remember that while = this region does require jit-lock action<br>those backends don't need to = be called.</div></div></blockquote><div><br></div><div>Thanks. = Very interesting approach, recycling the existing Qfontified = handler. I wonder though, if you have several different unrelated = functions calling `jit-lock-flush' with different = FONTIFICATION-FUNCTION's prior to jit-lock-fontify-now running on a = region, won't they step on each other? I.e it seems that you would = need to look for = <i>existing</i> jit-lock-already-fontified+fontified=3Dnil = properties over the region mentioned in jit-lock-flush and subtract the = passed FONTIFICATION-FUNCTION from the various values already found = there. Of course you'd also need to handle the case where you = "subtract it all the way to nil". That starts to sound like a lot = of property slinging, which might even dominate the work done. = <span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, = 0);">I don't guess there is a fast hidden</span></div><div><span = style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, = 0);"><br></span></div></div><blockquote style=3D"margin: 0 0 0 40px; = border: none; padding: 0px;"><div><div><font color=3D"#000000"><span = style=3D"caret-color: rgb(0, 0, = 0);"> (remove-from-text-property-lists beg end property = val-to-remove)</span></font></div></div></blockquote><div><div><br></div><= div>You could end also up with a quilted patchwork of different levels = of the already-fontified property before you clear them, which might = make jit-lock-fontify-now's job harder. Although for my particular = case I doubt this will be a problem:</div><div><br></div><div><ol = class=3D"MailOutline"><li>jit-lock-after-change will set fontified=3Dnil = (and btw, will probably also need to clear the already-fontified = property over the affected change region).</li><li>My tree-sitter based = code, upon edits and position-based scope changes, will use = jit-lock-flush to add already-fontified properties to the affected = locations where fontified=3Dt <span style=3D"caret-color: rgb(0, 0, = 0); color: rgb(0, 0, 0);">(if = any)</span>.</li></ol></div><div><br></div><div>I imagine that the = functions may also need a way to opt-out of "deferred contextual = refontification", for example if they add some other properties/overlays = orthogonal to face. Perhaps this could be done by having = jit-lock-context-fontify setup the "rest of the buffer" with = already-fontified =3D jit-lock-no-context-functions =E2=80=94 an = optional list of FONTIFICATION-FUNCTION's that don't require contextual = refontification.</div></div></body></html>= --Apple-Mail=_B12DECD9-6ADA-455A-AE8B-B1F55A046ABF--
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 3 Jun 2024 16:56:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 03 12:56:42 2024
Received: from localhost ([127.0.0.1]:49876 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sEAzC-0003iS-9t
for submit <at> debbugs.gnu.org; Mon, 03 Jun 2024 12:56:42 -0400
Received: from lists.gnu.org ([209.51.188.17]:34910)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sEAzA-0003iK-BY
for submit <at> debbugs.gnu.org; Mon, 03 Jun 2024 12:56:41 -0400
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 <monnier@HIDDEN>)
id 1sEAyq-0006a4-PQ
for bug-gnu-emacs@HIDDEN; Mon, 03 Jun 2024 12:56:22 -0400
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 <monnier@HIDDEN>)
id 1sEAyo-0006Fv-BF
for bug-gnu-emacs@HIDDEN; Mon, 03 Jun 2024 12:56:20 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6EBC0806D1;
Mon, 3 Jun 2024 12:56:16 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1717433771;
bh=EF24VqVw7GFBDT1r3S6ZnpVdWD+0mj9GFE1UdOU31Tw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=Vh+yv/3wlaplrOi+okLSJEPZoR/mKCiftCR3QMOdk5dqSDo2c9/KKrOTejN1Bu5r8
YyxI6JugULBGLCDfYYedQWAuTnOQAizfQUreBQBHexLzxQ9iEZsYSy+Vq0SGMFR6rK
I9YhCIE9eMLKl+qRoX6rGtsIQesk5hfgXcVdNlhVEwWvGtt+hmqdjyh2n7qu7Ofx4k
O/omD2PTQzf6jNg5nHIWEpElbNgNXhsF1bDY0LfQUagVSdsi07Bpb8KqOzoCPnYVKy
44Dl+lZ0IszZ8F+DbPOlVvvT71UQji6G9740dGUn99Afdi70vQ8LQ46aBQ4E65jhiJ
kF+y2fS94ldVg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2CF6280788;
Mon, 3 Jun 2024 12:56:11 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 04EB712041B;
Mon, 3 Jun 2024 12:56:10 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: JD Smith <jdtsmith@HIDDEN>
Subject: Re: Feature: unleash font-lock's secret weapon; handle Qfontified =
non-nil
In-Reply-To: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN> (JD Smith's
message of "Mon, 3 Jun 2024 12:35:02 -0400")
Message-ID: <jwvzfs29dyy.fsf-monnier+emacs@HIDDEN>
References: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN>
Date: Mon, 03 Jun 2024 12:56:13 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
Received-SPF: pass client-ip=132.204.25.50;
envelope-from=monnier@HIDDEN; 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,
T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
Cc: Dmitry Gutov <dmitry@HIDDEN>, bug-gnu-emacs@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
> In my particular case, I've been trying for several months to achieve
> a scheme for position-dependent additional fontification based on treesitter
> scope: think font-lock, but respondent not just to the contents of the
> buffer, but also the location of point within it. My particular application
> is drawing treesitter scope-aware indentation bars. There are many other
> applications you could envision, including many discussed here
> (e.g. bug#22404).
I've been meaning to add support for that to jit-lock.
Here's the design I have in mind:
From the outside, only one change, i.e. a new function
(jit-lock-flush BEG END FONTIFICATION-FUNCTION)
where FONTIFICATION-FUNCTION is the exact same function that was passed
to `jit-lock-register` (and is thus used as a kind of identifier of the
corresponding backend).
So in your case, when the position-dependent highlighting needs to be
updated, you'd request it by calling `jit-lock-flush`.
The way it would be implemented inside `jit-lock.el` is that
`jit-lock-flush` would set `fontified` to nil over that whole region,
but before that it would scan the region for those places where
`fontified` is non-nil, and set the `jit-lock-already-fontified` property
to the list of currently active backends (minus FONTIFICATION-FUNCTION),
so as to remember that while this region does require jit-lock action
those backends don't need to be called.
Then when `jit-lock-fontify-now` is called it will skip those backends
mentioned in `jit-lock-already-fontified`.
Stefan
bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 3 Jun 2024 16:35:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 03 12:35:35 2024 Received: from localhost ([127.0.0.1]:48240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sEAek-0002gn-S9 for submit <at> debbugs.gnu.org; Mon, 03 Jun 2024 12:35:35 -0400 Received: from lists.gnu.org ([209.51.188.17]:34398) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jdtsmith@HIDDEN>) id 1sEAei-0002ge-MG for submit <at> debbugs.gnu.org; Mon, 03 Jun 2024 12:35:33 -0400 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 <jdtsmith@HIDDEN>) id 1sEAeV-0000I8-G7 for bug-gnu-emacs@HIDDEN; Mon, 03 Jun 2024 12:35:19 -0400 Received: from mail-qk1-x733.google.com ([2607:f8b0:4864:20::733]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <jdtsmith@HIDDEN>) id 1sEAeT-0008EX-BS for bug-gnu-emacs@HIDDEN; Mon, 03 Jun 2024 12:35:19 -0400 Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-794ad6d2884so322719085a.2 for <bug-gnu-emacs@HIDDEN>; Mon, 03 Jun 2024 09:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717432515; x=1718037315; darn=gnu.org; h=to:cc:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=zz6I/Lk+6RhEsaBG6PbESt19sjaL3FyGNonAdPPG4vk=; b=FhTIpfroCRqvBzhA8xHMEIgZJvDWe8I2OuaswOeochwC+n+zBGh0ub3x0dfXKe0bDy MySyPi/9vkAgUGYYivWOPhSk/imGOyKzty8kEq7+EfTnbVgh1P9azHPPgYSxEgwouyA+ tE9k1FXIvuOKfTiLabdAbnKXmGgCmQNWQznB8gILRF4KVtIVFYk3vNcK4aoQJjLdmjjC 55AvG7ElUHGudSvnwr6zzPx58y5L4PO3uKVpmTGsbX8Pi7kI/atFpC+c8ruyOdqYtvg5 cYkpDmu9XkBsi1OpPi+Jv2j2wLbCAR95toC81F68YcYmm6KnV1USxZtUCQU9A2SuAyNm W7jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717432515; x=1718037315; h=to:cc:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zz6I/Lk+6RhEsaBG6PbESt19sjaL3FyGNonAdPPG4vk=; b=daOZ488cT7VKfDarGhtVyW5bj7m1laKww139NEdbkcCptRdEVsT7gcSq8kPyRhWeBh JJavkAO3WpR9c7W83QQDKqPQMCvlrWvL2sL3Tfd1nubEDozHNs8Vr1UA88EduvqZltlT CPOYcbMv0OlcEkyWHq5q1K3UMzHbGNJCz6JpHy4PKnyN1L/yo/X1II0HwEdscf+eObvo NZ2D33W0D8/uMHkQyhpdQltoIThVaGeBkNSX7tiAODjZzibj0kKDMDESoojER70pr8Rp ON3P7RRkq/2tCoeK3l6ZNfzqKMAUtRQMf477vnXVmo/QYl1eN5Gm9uNz5EHaiSL91n8O 4ihg== X-Gm-Message-State: AOJu0YwZ+pl+SI94u3UyGcHQmobaIqKUZkJBFfQ18Z1hxBphkN8JpRQa ugNzUepHuxsxqkUhmhWYeZbe6TzmjOWWFyBnF2jan5QooZVYDRC8WtX4Iw== X-Google-Smtp-Source: AGHT+IEz94jTfbqU73LK+TJhAUTiawAaX1eikG7x70Na5azZfKWpF5Bq2OlyVSjiARIn7l7ewr6sYg== X-Received: by 2002:a05:620a:28d1:b0:794:fa3a:4273 with SMTP id af79cd13be357-794fa3a43cbmr1141647985a.5.1717432514533; Mon, 03 Jun 2024 09:35:14 -0700 (PDT) Received: from smtpclient.apple ([131.183.131.33]) by smtp.gmail.com with ESMTPSA id af79cd13be357-794f305f564sm296033885a.86.2024.06.03.09.35.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jun 2024 09:35:13 -0700 (PDT) From: JD Smith <jdtsmith@HIDDEN> Content-Type: multipart/alternative; boundary="Apple-Mail=_C32D70E2-3A2C-4DA1-88B6-484F0400730B" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil Message-Id: <8A929E16-AF10-4D2B-AD71-AEAD4435F016@HIDDEN> Date: Mon, 3 Jun 2024 12:35:02 -0400 To: bug-gnu-emacs@HIDDEN X-Mailer: Apple Mail (2.3774.500.171.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::733; envelope-from=jdtsmith@HIDDEN; helo=mail-qk1-x733.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Dmitry Gutov <dmitry@HIDDEN>, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) --Apple-Mail=_C32D70E2-3A2C-4DA1-88B6-484F0400730B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =09 Many emacs packages concern themselves with updating the display = just-in-time, prior to final redisplay. They may apply overlays, = additional custom fontification, images or stipples, etc. And they need = this to happen before redisplay, to avoid flashing temporarily untreated = text. They may be slow to run, so cannot afford to update the entire = buffer when an update is needed. And they may update relatively rapidly = based on point, edits, or external events. Package authors who encounter this class of problem may reach for = post-command-hook's, pre-redisplay-functions, window-scroll-functions, = etc. But in all cases they will face an unfortunate reality: in many = cases you cannot know the window bounds accurately until after redisplay = has completed. The docs are very up front about this, but don't offer a = great solution. You can force a window bounds update with (window-end = win t), but that appears to incur the full cost of redisplay, and in = many cases costs 5-10x as much as the work you wanted to do in the = displayed portion of the buffer itself, and does not always work. Lots = of discussion has occurred on this topic, with ideas like = post-redisplay-hook considered but never implemented. These are effectively the same problems that font-lock faces. But = font-lock (via jit-lock) has a secret weapon it alone may use: the = fontified=3Dnil handler. As I understand it, redisplay looks for = fontified=3Dnil and calls fontification-functions (usually containing = jit-lock-function) as many times as needed to achieve fontification of = the about-to-be displayed window contents. jit-lock-function adds face = information to chunks of jit-lock-chunk-size (1500, by default), and = gets called as many times as needed. This is very efficient, compared = to anything which can be done in elisp. What I'm proposing is to open the use of font-lock's secret weapon for = others. You could imagine many ways to achieve this, but a simple one = might be: Only Qfontified =3D t indicates "clean" buffer text. For other values (including nil), if fontification-functions is a list, = call each function with the start position of "dirty" buffer text, same = as normal. If fontification-functions is instead an alist, consult the value of = Qfontitified and call the correct function(s) in the list whose key is = that value=20 (Optional) The key value `t' indicates a function to be called with all = Qfontified values, passed to the function in a second argument. In my particular case, I've been trying for several months to achieve a = scheme for position-dependent additional fontification based on = treesitter scope: think font-lock, but respondent not just to the = contents of the buffer, but also the location of point within it. My = particular application is drawing treesitter scope-aware indentation = bars. There are many other applications you could envision, including = many discussed here (e.g. bug#22404).=20 Font-lock can handle this type of things very well (by using its secret = weapon). But what I (and many packages) want to do is in addition to = font-lock. You can of course do this within font-lock: just consult = treesitter scope and set fontified=3Dnil across potentially large = regions of the buffer -- regions which may change rapidly as point = moves. It will work well-enough, but it ends up doing a ton of wasted = extra work as point moves around, continuously fully refontifying the = underlying text, text which was perfectly well fontified already. I have tried window-scroll-functions, post-command-hooks, = jit-lock-functions, etc. All come back to the same issue that no doubt = originally motivated jit-lock's need for special handler support: you = don't know what the window will contain at the right time.= --Apple-Mail=_C32D70E2-3A2C-4DA1-88B6-484F0400730B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dus-ascii"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;"><span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span><div>Many = emacs packages concern themselves with updating the display = just-in-time, prior to final redisplay. They may apply overlays, = additional custom fontification, images or stipples, etc. And they = need this to happen before redisplay, to avoid flashing temporarily = untreated text. They may be slow to run, so cannot afford to = update the entire buffer when an update is needed. And they may = update relatively rapidly based on point, edits, or external = events.</div><div><br></div><div>Package authors who encounter this = class of problem may reach for post-command-hook's, = pre-redisplay-functions, window-scroll-functions, etc. But in all = cases they will face an unfortunate reality: in many cases you cannot = know the window bounds accurately until <i>after </i>redisplay has = completed. The docs are very up front about this, but don't offer = a great solution. You can force a window bounds update with<span = style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, = 0);"> </span><span style=3D"caret-color: rgb(0, 0, 0); color: = rgb(0, 0, 0);">(window-end win t)</span>, but that appears to incur the = full cost of redisplay, and in many cases costs 5-10x as much as the = work you wanted to do in the displayed portion of the buffer itself, and = does not always work. <font color=3D"#000000"><span = style=3D"caret-color: rgb(0, 0, 0);">Lots of discussion has occurred on = this topic, with ideas like post-redisplay-hook considered but never = implemented.</span></font></div><div><br></div><div>These are = effectively the same problems that font-lock faces. But font-lock = (via jit-lock) has a <i>secret weapon</i> it alone may use: the = fontified=3Dnil handler. As I understand it, redisplay looks for = fontified=3Dnil and calls fontification-functions (usually containing = jit-lock-function) as many times as needed to achieve fontification of = the about-to-be displayed window contents. jit-lock-function adds = face information to chunks of jit-lock-chunk-size (1500, by default), = and gets called as many times as needed. This is very efficient, = compared to anything which can be done in = elisp.</div><div><br></div><div>What I'm proposing is to open the use of = font-lock's secret weapon for others. You could imagine many ways = to achieve this, but a simple one might be:</div><div><br></div><div><ul = class=3D"MailOutline"><li><i>Only</i> Qfontified =3D t indicates "clean" = buffer text.</li><li>For other values (including nil), if <span = style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, = 0);">fontification-functions</span> is a list, call each function = with the start position of "dirty" buffer text, same as = normal.</li><li>If fontification-functions is instead an alist, consult = the value of Qfontitified and call the correct function(s) in the list = whose key is that value </li><li>(Optional) The key value `t' = indicates a function to be called with <i>all</i> Qfontified = values, passed to the function in a second = argument.</li></ul></div><div><br></div><div>In my particular case, I've = been trying for several months to achieve a scheme for = position-dependent additional fontification based on treesitter scope: = think font-lock, but respondent not just to the contents of the buffer, = but also the <i>location of point</i> within it. My particular = application is drawing treesitter scope-aware indentation bars. = There are many other applications you could envision, including = many discussed here (e.g. = bug#22404). </div><div><br></div><div>Font-lock can handle this = type of things very well (by using its secret weapon). But what I = (and many packages) want to do is <i>in addition</i> to font-lock. = You can of course do this within font-lock: just consult = treesitter scope and set fontified=3Dnil across potentially large = regions of the buffer -- regions which may change rapidly as point = moves. It will work well-enough, but it ends up doing a ton of = wasted extra work as point moves around, continuously fully refontifying = the underlying text, text which was perfectly well fontified = already.</div><div><br></div><div>I have tried window-scroll-functions, = post-command-hooks, jit-lock-functions, etc. All come back to the = same issue that no doubt originally motivated jit-lock's need for = special handler support: you don't know what the window will contain at = the right time.</div></body></html>= --Apple-Mail=_C32D70E2-3A2C-4DA1-88B6-484F0400730B--
JD Smith <jdtsmith@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#71345; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.