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: Mon, 12 Apr 2021 23:33:59 -0400 Message-ID: <98C7D46D-F01E-4C6B-8618-020BB76664C4@gmail.com> References: <7A948673-E156-42BA-BA50-E91986908BB5@gmail.com> <65B869A0-CB0B-43C1-90EA-E2B259A74589@gmail.com> <0A6735A5-ABC0-48B0-B7C0-EACF5D85A32B@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_640DC9AE-7EB2-47F3-B355-6981E8ABB87B" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1152"; 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 Tue Apr 13 05:34:42 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 1lW9p4-0000Eh-CX for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Apr 2021 05:34:42 +0200 Original-Received: from localhost ([::1]:54728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lW9p3-0007Pl-CU for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Apr 2021 23:34:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49344) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lW9oS-0006nO-3p for emacs-devel@gnu.org; Mon, 12 Apr 2021 23:34:04 -0400 Original-Received: from mail-io1-xd2b.google.com ([2607:f8b0:4864:20::d2b]:36508) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lW9oQ-0004uW-7J for emacs-devel@gnu.org; Mon, 12 Apr 2021 23:34:03 -0400 Original-Received: by mail-io1-xd2b.google.com with SMTP id d5so6250308iof.3 for ; Mon, 12 Apr 2021 20:34:01 -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=0XvP/Dp5gr6DLp5XMXPyNMndMaPLJXnlH8HPBSD1TJI=; b=QqzOXxYO0SRPa/jC/nOltsTh0dTrtGCs6S8S19Sv8Y0s6iO0+rTAL7d6GBIklBPSEn 7YOoWz7Fs55RgfhnOlrIZL/g+VMpVoOqFu3FHAw8/3f6JJlQ3AwK7b2iCzP2N2DuSdI9 /YAmgHyxcTHlMCyn+1Fi6+FJ5eJBECUjIkLb24G2KPigI1b6fS77uBlbUuyoPZhwey30 XuAKxrJEGUY+BilkyBk7+qsjdVCgGWebP3EDKrjZcbxRdV5kts4kLR2EL6mBrbIEbe9t 5+TZgMI0AkiqLxu8rokKAEbh1p+zdYxreOsQc2CR4FsCUKSzuM566zQqA0DaqhT8PC9u 9+kA== 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=0XvP/Dp5gr6DLp5XMXPyNMndMaPLJXnlH8HPBSD1TJI=; b=iJitGg/G2210mNrnQ50IR//bY9E7X9UJWWvPi66vRnz/HcuGZFNcQwxssC4H7y4LOD TzyQvTTsUKQh6EyDi65hqCwFxWyIwXQqfIUdvUifCX6P/PZDSKZQ1gTMR5A2mit+V4M5 YV87Z1l5hKGw2+7OKop8V8KRhLoUkj0toRGRvVsxtybVeF2uSclH4wQTjJAerZRKe10k 4K0FBMdYplcACgzamyT9oSQVMPiIBdhq0Zw+GKFSJ1KSCEPt/GBktA9tYG3KFDO2353d 5hkm+8kIury+GIUrIQLTBl4ds7VwmjTFREcWP/6xETsX1JpAuoG+zq39AmNoy2uvzPzF 0x/A== X-Gm-Message-State: AOAM532ezc92zh6MLIYIAjT3RJAkz9YrsjwDPyrtXXiK+FSCgxiDrmIt O+ehDuINY8kUMT+YJtTk3+c= X-Google-Smtp-Source: ABdhPJxh/1XlM9kZ/JIQBMk4uVdDFaU2fpV8cqZ8HKY1oU68AP77b2Zy3xyidcq2ez+tqPUudRHZ6g== X-Received: by 2002:a6b:be06:: with SMTP id o6mr8969407iof.193.1618284840871; Mon, 12 Apr 2021 20:34:00 -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 d7sm6258343ion.39.2021.04.12.20.34.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Apr 2021 20:34:00 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3608.120.23.2.4) Received-SPF: pass client-ip=2607:f8b0:4864:20::d2b; envelope-from=jdtsmith@gmail.com; helo=mail-io1-xd2b.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:267990 Archived-At: --Apple-Mail=_640DC9AE-7EB2-47F3-B355-6981E8ABB87B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 12, 2021, at 10:07 PM, Stefan Monnier = wrote: >=20 > Calling `font-lock-flush` or `font-lock-ensure` from = font-lock-keywords > is quite odd. I'd call something like `font-lock-fontify-region` = instead. Using `font-lock-fontify-region` instead causes Emacs to become mostly = unresponsive. Sending a USR2 reveals: Debugger entered--entering a function: * #f(compiled-function () #)() font-lock-default-fontify-region(188 189 nil) font-lock-fontify-region(188 189) #f(compiled-function (fun) #)(font-lock-fontify-region) run-hook-wrapped(#f(compiled-function (fun) #) font-lock-fontify-region) jit-lock--run-functions(188 189) jit-lock-fontify-now(188 688) jit-lock-function(188) redisplay_internal\ \(C\ function\)() =20 > There's one thing with which you might want to be careful, tho, which = is > the `syntax-ppss` state. You might want to `narrow-to-region` around > the call to `font-lock-fontify-region` (maybe narrow to = pmark...(point-max)?). >=20 > This is because in a shell buffer, some of the past interactions may > have been truncated (e.g. by `comint-truncate-buffer`), so you may end > up with (point-min) being in the middle of a string or something. > [ Similar problems can occur if the prompt itself contains funny = characters > like unmatched quotes. or if past interactions include output which > is not lexically valid Python code. ] Well hmm, this is a bummer. l tested for this issue by inserting an = entirely unmatched quote: In [12]: print(chr(39)) ' and this does affect the syntax (everything is a string). But = unfortunately narrowing as follows doesn=E2=80=99t seem to fix this: (save-restriction (narrow-to-region pmark (point-max)) (with-syntax-table python-mode-syntax-table (font-lock-flush start limit) (font-lock-ensure start limit))))))) I=E2=80=99m not sure it=E2=80=99s the same thing, but I found a related = issue with `indent-for-tab-command'. In attempting to ignore the prompt = for computing indentation, I narrowed to a region which excluded it, but = indent.el calls `indent--funcall-widened=E2=80=99, which undoes my = narrowing! =20 Is there any way to specify "narrow to this region and don=E2=80=99t let = anybody widen it(!)"?= --Apple-Mail=_640DC9AE-7EB2-47F3-B355-6981E8ABB87B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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

Calling `font-lock-flush` or = `font-lock-ensure` from font-lock-keywords
is quite odd. =  I'd call something like `font-lock-fontify-region` instead.

Using = `font-lock-fontify-region` instead causes Emacs to become mostly = unresponsive.  Sending a USR2 reveals:

Debugger entered--entering a function:
* = #f(compiled-function () #<bytecode = 0x1fed77d1f329>)()
  = font-lock-default-fontify-region(188 189 nil)
  = font-lock-fontify-region(188 189)
  #f(compiled-function = (fun) #<bytecode = 0x1fed77d1f2f9>)(font-lock-fontify-region)
  = run-hook-wrapped(#f(compiled-function (fun) #<bytecode = 0x1fed77d1f2f9>) font-lock-fontify-region)
  = jit-lock--run-functions(188 189)
  = jit-lock-fontify-now(188 688)
  = jit-lock-function(188)
  redisplay_internal\ \(C\ = function\)()  

There's one = thing with which you might want to be careful, tho, which is
the `syntax-ppss` state.  You might want to = `narrow-to-region` around
the call to = `font-lock-fontify-region` (maybe narrow to pmark...(point-max)?).

This is because in a shell buffer, some of the = past interactions may
have been truncated (e.g. by = `comint-truncate-buffer`), so you may end
up with = (point-min) being in the middle of a string or something.
[ = Similar problems can occur if the prompt itself contains funny = characters
 like unmatched quotes.  or if past = interactions include output which
 is not lexically = valid Python code.  ]

Well hmm, this is a bummer.  l tested for this issue by = inserting an entirely unmatched quote:

In [12]: = print(chr(39))
'

and this does affect = the syntax (everything is a string).  But unfortunately narrowing = as follows doesn=E2=80=99t seem to fix this:

  =  (save-restriction
  =    (narrow-to-region pmark (point-max))
=      (with-syntax-table = python-mode-syntax-table
= (font-lock-flush start limit)
= (font-lock-ensure start limit)))))))
I=E2=80=99m not sure it=E2=80=99s the = same thing, but I found a related issue with `indent-for-tab-command'. =  In attempting to ignore the prompt for computing indentation, I = narrowed to a region which excluded it, but indent.el calls = `indent--funcall-widened=E2=80=99, which undoes my = narrowing!  

Is there any way to specify "narrow to this region and = don=E2=80=99t let anybody widen it(!)"?
= --Apple-Mail=_640DC9AE-7EB2-47F3-B355-6981E8ABB87B--