From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.bugs Subject: bug#71345: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil Date: Wed, 5 Jun 2024 11:52:37 -0400 Message-ID: <9B55EAF1-C0FC-4B5B-A438-3B3C33430816@gmail.com> References: <86msnzk4pl.fsf@gnu.org> <64828D71-7A1D-4826-811A-A30E870358C7@gmail.com> <86a5jzjvar.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_1601438C-A456-489C-90F9-02F0CA7219DD" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9800"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71345@debbugs.gnu.org, Stefan Monnier To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 05 18:56:13 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sEtvo-0002Fy-MC for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Jun 2024 18:56:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sEtvS-00067N-C5; Wed, 05 Jun 2024 12:55:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sEtvQ-00066p-Ug for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2024 12:55:48 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sEtvQ-0005SS-MW for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2024 12:55:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sEtve-00025O-Ni for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2024 12:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: JD Smith Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Jun 2024 16:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71345 X-GNU-PR-Package: emacs Original-Received: via spool by 71345-submit@debbugs.gnu.org id=B71345.17176065457963 (code B ref 71345); Wed, 05 Jun 2024 16:56:02 +0000 Original-Received: (at 71345) by debbugs.gnu.org; 5 Jun 2024 16:55:45 +0000 Original-Received: from localhost ([127.0.0.1]:48648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sEtvL-00024J-Lk for submit@debbugs.gnu.org; Wed, 05 Jun 2024 12:55:44 -0400 Original-Received: from mail-qk1-f170.google.com ([209.85.222.170]:59822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sEtvJ-00023v-Hj for 71345@debbugs.gnu.org; Wed, 05 Jun 2024 12:55:42 -0400 Original-Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-7951c762462so123433185a.3 for <71345@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) Original-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) In-Reply-To: <86a5jzjvar.fsf@gnu.org> X-Mailer: Apple Mail (2.3774.500.171.1.1) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:286621 Archived-At: --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 = wrote: >=20 >> From: JD Smith >> Cc: monnier@iro.umontreal.ca, 71345@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

On Jun 5, 2024, at 10:53=E2=80=AFAM, Eli Zaretskii = <eliz@gnu.org> wrote:

From: JD Smith <jdtsmith@gmail.com>
Cc: = monnier@iro.umontreal.ca, 71345@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 =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.  

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:

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 =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?

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:

>>>>>> 
;; 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': 
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--