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.devel Subject: Re: Selective font-locking? Date: Sun, 11 Apr 2021 16:54:28 -0400 Message-ID: <65B869A0-CB0B-43C1-90EA-E2B259A74589@gmail.com> References: <7A948673-E156-42BA-BA50-E91986908BB5@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_CAD6FF82-451E-45EF-B439-588128927C58" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24060"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 11 22:56:49 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lVh8S-00064c-J3 for ged-emacs-devel@m.gmane-mx.org; Sun, 11 Apr 2021 22:56:48 +0200 Original-Received: from localhost ([::1]:55504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVh8R-0002Pw-Kn for ged-emacs-devel@m.gmane-mx.org; Sun, 11 Apr 2021 16:56:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39140) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lVh6K-0001gg-0C for emacs-devel@gnu.org; Sun, 11 Apr 2021 16:54:38 -0400 Original-Received: from mail-il1-x12a.google.com ([2607:f8b0:4864:20::12a]:36541) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lVh6F-0002xb-4l for emacs-devel@gnu.org; Sun, 11 Apr 2021 16:54:34 -0400 Original-Received: by mail-il1-x12a.google.com with SMTP id t14so9279209ilu.3 for ; Sun, 11 Apr 2021 13:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5tn96d5fmEBZxZf31HVWk0FTochuy9pO7m468lS/4lE=; b=t2EbQVL5npbguqFOfZbUJWTFIyiMnMWuJ0A6M+ZPcK9u9ExWG8nW3jLiOQLyfMKeBZ ieVAsAZpcNMFcm+DpIpFhDUOUmvMY1jeU32NFpbd9afvG8FmzCR3vZEHX96IHfdOu6xg RuXeVfkZh6nz2VcYq6T9GexR0GIzFNOo5nq+WKw65t/JdFeL/D8U/Q1L9/0qV/0BtlTe eRJ5H3a+CX2IjjtoarptD1XqI3w3wfKDvJ1jE3vOmOYIH5Gj+cCV8osrSx3HSw2MIvnM Kl3Jl2+ibnInC3p9zV8IGW42XAZYQAaH1ziSx1nwAth0vTxQTJKuxOZvT0LZ6i1qwSqG uwfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5tn96d5fmEBZxZf31HVWk0FTochuy9pO7m468lS/4lE=; b=aY7nGcSevP3iJy+PKsjThrdnl9T1EXXDOZIzfjZ0t5H7pP5W79wKqlmIIPo4SV3L+l DKQB47WiqpZIDu6RSomWH78xGK7eEzkSiVM7kM7yDP29dg/XCO5fTNiKJ4lzv6Qzex+i IUjt7sVDLBxD5e6Svip8kS2KdY7LywqfumrbPum1c8i1Mx4+s7pz4DGiuEwPjW6vq5L+ yO4xlJQqOeuKsw7/9SgyCQeEoF1I6ImL9BwX5dEzooQ6AArDGrOzVfWBbW6Q4ijc33Xp 8HKMcZH1sQkXhsR2V3/i139eUe2NfdsyzBr8YQPj5ZKnWVaP4r6zwCZerCgYxUq1vWoX jRBw== X-Gm-Message-State: AOAM533unYQtaT8Xui1bUPSOnA/8xfDVgvlMb2pGAmyukxk75kOhl9xo y1Ed8Z1m23QD3+ssIkaLWmtsoi6VtzAYpg== X-Google-Smtp-Source: ABdhPJwIp33I/cG+iG+OrEuAk4UAfX+5e9l4T6WXkmrng5+eR35geGg0O8f7igYy/djyAltVL94rLw== X-Received: by 2002:a92:4a12:: with SMTP id m18mr20060914ilf.296.1618174469884; Sun, 11 Apr 2021 13:54:29 -0700 (PDT) Original-Received: from [192.168.0.118] (cm-134-228-54-223.buckeyecom.net. [134.228.54.223]) by smtp.gmail.com with ESMTPSA id e2sm4518344iov.26.2021.04.11.13.54.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Apr 2021 13:54:29 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3608.120.23.2.4) Received-SPF: pass client-ip=2607:f8b0:4864:20::12a; envelope-from=jdtsmith@gmail.com; helo=mail-il1-x12a.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 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267913 Archived-At: --Apple-Mail=_CAD6FF82-451E-45EF-B439-588128927C58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Definitely worth trying, thanks. I came up with: (defun python-shell-multiline--apply-font-lock (limit) (let ((end (cdr-safe comint-last-prompt))) (if (and end (> limit end)) (let ((font-lock-keywords python-font-lock-keywords) (font-lock-syntactic-face-function #'python-font-lock-syntactic-face-function) (start (max end (point)))) (font-lock-flush start limit) (font-lock-ensure start limit))))) (set (make-local-variable 'font-lock-keywords) '(python-shell-multiline--apply-font-lock))) I can verify that font-lock-ensure is being called on an appropriate = region (lots of times). With either font-lock-flush or = font-lock-ensure, no actual fontification occurs. With both of these = together (as above), this error is signaled: Error during redisplay: (jit-lock-function 179) signaled (void-function = python-font-lock-keywords-level-1) Note that python-font-lock-keywords is a *list* beginning with this = symbol: Python-font-lock-keywords is a variable defined in =E2=80=98python.el=E2=80= =99. Its value is (python-font-lock-keywords-level-1 python-font-lock-keywords-level-1 = python-font-lock-keywords-level-2 = python-font-lock-keywords-maximum-decoration) Not sure why jit-lock-function would be evaluating it like an sexp. > On Apr 11, 2021, at 12:31 PM, Stefan Monnier = wrote: >=20 >> But then, why bother round-tripping text out to a special-use buffer = anyway, >> vs. just letting font-lock operate in-situ in the shell buffer itself = using >> python-mode=E2=80=99s fairly simple font-lock-defaults. The only = thing needed to >> make this work is asking font-lock to ignore all the text with = =E2=80=98field of >> =E2=80=98output? =20 >=20 > Maybe you can try something like the following? >=20 > (defvar python--font-lock-keywords ...) > (defvar python-font-lock-keywords > '(python--apply-font-lock)) > (defun python--apply-font-lock (limit) > (while (< (point) limit) > (let ((next-boundary (find-next-boundary limit))) > (if (we-should-skip-this-block) > (goto-char next-boundary) > (let ((font-lock-keywords python--font-lock-keywords)) > (font-lock-ensure (point) limit)))))) >=20 >=20 > -- Stefan >=20 --Apple-Mail=_CAD6FF82-451E-45EF-B439-588128927C58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Definitely worth trying, thanks.  I came up with:

(defun = python-shell-multiline--apply-font-lock (limit)
  (let ((end (cdr-safe = comint-last-prompt)))
    (if (and end (> limit = end))
= (let ((font-lock-keywords = python-font-lock-keywords)
    =  (font-lock-syntactic-face-function
      = #'python-font-lock-syntactic-face-function)
     (start (max = end (point))))
=  (font-lock-flush start limit)
 (font-lock-ensure start = limit)))))

(set (make-local-variable = 'font-lock-keywords)
      =  '(python-shell-multiline--apply-font-lock)))

I = can verify that font-lock-ensure is being called on an appropriate = region (lots of times).  With either font-lock-flush or = font-lock-ensure, no actual fontification occurs.  With both of = these together (as above), this error is signaled:

Error during redisplay: (jit-lock-function 179) signaled = (void-function = python-font-lock-keywords-level-1)

Note that = python-font-lock-keywords is a *list* beginning with this = symbol:

Python-font-lock-keywords is a variable defined in = =E2=80=98python.el=E2=80=99.
Its value is
(python-font-lock-keywords-level-1 = python-font-lock-keywords-level-1 python-font-lock-keywords-level-2 = python-font-lock-keywords-maximum-decoration)

Not= sure why jit-lock-function would be evaluating it like an = sexp.

On Apr 11, 2021, at 12:31 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

But then, why bother = round-tripping text out to a special-use buffer anyway,
vs. = just letting font-lock operate in-situ in the shell buffer itself = using
python-mode=E2=80=99s fairly simple = font-lock-defaults. The only thing needed to
make this = work is asking font-lock to ignore all the text with =E2=80=98field = of
=E2=80=98output?  

Maybe you can try something like the following?

   (defvar = python--font-lock-keywords ...)
   (defvar = python-font-lock-keywords
=      '(python--apply-font-lock))
=    (defun python--apply-font-lock (limit)
=      (while (< (point) limit)
=        (let ((next-boundary = (find-next-boundary limit)))
=          (if = (we-should-skip-this-block)
=             &n= bsp;(goto-char next-boundary)
=            (let = ((font-lock-keywords python--font-lock-keywords))
=             &n= bsp;(font-lock-ensure (point) limit))))))

-- Stefan


= --Apple-Mail=_CAD6FF82-451E-45EF-B439-588128927C58--