From: Gregory Heytings <gregory@heytings.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: master 2399541: Remove font-lock toggle from font-lock-update
Date: Thu, 25 Mar 2021 20:58:30 +0000 [thread overview]
Message-ID: <fa05cc9782c6e2b5deb5@heytings.org> (raw)
In-Reply-To: <jwvr1k3e4iq.fsf-monnier+emacs@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3205 bytes --]
>
> That's the wrong question, since my beef is about the definition of what
> the function should do, as opposed to how it's implemented.
>
I think the simplest way to express what the function should do is: if
something is wrong with the fontification, fix it. (And with a prefix
argument, toggle fontification.)
That's basically what Eli used font-lock-fontify-block for, for instance.
Someone else said something like "I did not know that
font-lock-fontify-block exists, when the fontification is wrong, I just
turn font-lock-mode off and on".
>
> [ Tho maybe I'd prefer if it used `font-lock-flush` or
> `font-lock-ensure`. ]
>
Yes, but alas that doesn't work e.g. when yanking a font-locked string
into a text-mode buffer.
>>> I'd much prefer a longer `font-lock-fontify-diwm` which tries to
>>> reproduce more or less the same behavior as your favorite, but by
>>> explicitly testing the different circumstances you care about.
>>
>> Could you perhaps give an example of such a circumstance and its
>> corresponding action?
>
> The main "circumstances" that matter are whether the font-lock machinery
> is activated and whether font-lock-mode is nil or not.
>
Are these two separate conditions? Or does font-lock-mode t imply that
the font-lock machinery is activated? (Apart from the case where someone
would do (progn (font-lock-mode -1) (setq font-lock-mode t)) of course.)
>
> Currently, I've heard mention of two use cases for
> font-lock-fontify-block:
>
> ;; - Correct misfontification when fontification is highly context-dependent
> ;; and has a bug (typically associated with multiline constructs).
> ;; `font-lock-flush` should work as well in that case.
> ;; - Removing fontification, e.g. when yanking font-locked strings into
> ;; a text-mode buffer. Not sure if the intention would be to generalize
> ;; this to all buffers with a nil `font-lock-keywords` or also to buffers
> ;; where font-lock-mode is disabled.
>
There is another use case I think, which is close to your first use case,
and is perhaps the most common one: the fontification is not what you
expect (say, you're inside a function and the fontification indicates
you're inside a comment), and you are not sure whether it's because the
fontification has not yet been updated, or because you indeed forgot to
close a comment. A refontifcation is useful in that case, too.
Another similar case is when you know that the fontification should change
and do not want to wait for the refontification to take place (say, you
open a comment, and want immediately see the effect).
In those case font-lock-flush should work well, too.
>
> Maybe the docstring should describe just those behaviors, and the
> implementation could then implement them explicitly, rather than have
> that grow accidentally as a result of the implementation.
>
Is a KISS approach not better? Could it do something wrong? What would
be the benefit of identifying use cases one by one and adding them to a
(presumably much more complex) function?
I attach an updated patch; it occurred to me that with outline-mode and
friends, "far away from point" might not be enough to cover the window.
[-- Attachment #2: Type: text/x-diff, Size: 3481 bytes --]
From c77e6e67da31b918d92aacce1c86ac819cfd5fcc Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Thu, 25 Mar 2021 20:08:53 +0000
Subject: [PATCH] Improve font-lock-update and rename it to font-lock-dwim
* lisp/font-lock.el (font-lock-dwim): Renamed from 'font-lock-update'.
Only refontify the region when it is active. Do not refontify too
large buffers at once.
* lisp/bindings.el (ctl-x-x-map): Adjust the command name.
* etc/NEWS: Adjust the command name.
---
etc/NEWS | 4 ++--
lisp/bindings.el | 2 +-
lisp/font-lock.el | 14 +++++++++-----
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/etc/NEWS b/etc/NEWS
index 68812c64cc..58cc4a2b82 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -94,7 +94,7 @@ useful on systems such as FreeBSD which ships only with "etc/termcap".
* Changes in Emacs 28.1
+++
-** New command 'font-lock-update', bound to 'C-x x f'.
+** New command 'font-lock-dwim', bound to 'C-x x f'.
This command updates the syntax highlighting in this buffer.
** The new NonGNU ELPA archive is enabled by default alongside GNU ELPA.
@@ -255,7 +255,7 @@ The 'C-x x' keymap now holds keystrokes for various buffer-oriented
commands. The new keystrokes are 'C-x x g' ('revert-buffer'),
'C-x x r' ('rename-buffer'), 'C-x x u' ('rename-uniquely'), 'C-x x n'
('clone-buffer'), 'C-x x i' ('insert-buffer'), 'C-x x t'
-('toggle-truncate-lines') and 'C-x x f' ('font-lock-update').
+('toggle-truncate-lines') and 'C-x x f' ('font-lock-dwim').
---
** Commands 'set-frame-width' and 'set-frame-height' can now get their
diff --git a/lisp/bindings.el b/lisp/bindings.el
index 6eac528eb6..6f25e9738a 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -1432,7 +1432,7 @@ ctl-x-map
(defvar ctl-x-x-map
(let ((map (make-sparse-keymap)))
- (define-key map "f" #'font-lock-update)
+ (define-key map "f" #'font-lock-dwim)
(define-key map "g" #'revert-buffer)
(define-key map "r" #'rename-buffer)
(define-key map "u" #'rename-uniquely)
diff --git a/lisp/font-lock.el b/lisp/font-lock.el
index 82915d8c8b..1800f0b56d 100644
--- a/lisp/font-lock.el
+++ b/lisp/font-lock.el
@@ -1120,15 +1120,19 @@ font-lock-ensure
(funcall font-lock-ensure-function
(or beg (point-min)) (or end (point-max)))))
-(defun font-lock-update (&optional arg)
+(defun font-lock-dwim (&optional arg)
"Updates the syntax highlighting in this buffer.
-Refontify the accessible portion of this buffer, or enable Font Lock mode
-in this buffer if it is currently disabled. With prefix ARG, toggle Font
-Lock mode."
+Enable Font Lock mode if it is disabled. Otherwise, refontify the region
+if it is active, or a large part of the accessible portion of the buffer.
+Otherwise, with prefix ARG, toggle Font Lock mode."
(interactive "P")
(save-excursion
(if (and (not arg) font-lock-mode)
- (font-lock-fontify-region (point-min) (point-max))
+ (if (use-region-p)
+ (font-lock-fontify-region (region-beginning) (region-end))
+ (font-lock-flush (point-min) (point-max))
+ (font-lock-fontify-region (max (point-min) (min (- (point) 50000) (window-start)))
+ (min (point-max) (max (+ (point) 50000) (window-end)))))
(font-lock-unfontify-region (point-min) (point-max))
(font-lock-mode 'toggle))))
--
2.30.2
next prev parent reply other threads:[~2021-03-25 20:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210324143048.23515.75257@vcs0.savannah.gnu.org>
[not found] ` <20210324143050.40C6E20D10@vcs0.savannah.gnu.org>
2021-03-24 15:23 ` master 2399541: Remove font-lock toggle from font-lock-update Stefan Monnier
2021-03-24 15:28 ` Lars Ingebrigtsen
2021-03-24 15:47 ` Stefan Monnier
2021-03-24 15:29 ` Paul W. Rankin via Emacs development discussions.
2021-03-24 15:32 ` Gregory Heytings
2021-03-24 15:43 ` Lars Ingebrigtsen
2021-03-24 16:03 ` Lars Ingebrigtsen
2021-03-24 17:43 ` Paul W. Rankin via Emacs development discussions.
2021-03-24 17:49 ` Lars Ingebrigtsen
2021-03-24 22:07 ` Stefan Monnier
2021-03-24 22:27 ` Gregory Heytings
2021-03-25 13:52 ` Stefan Monnier
2021-03-25 20:58 ` Gregory Heytings [this message]
2021-03-25 22:39 ` Stefan Monnier
2021-03-29 9:44 ` Gregory Heytings
2021-03-29 13:00 ` Stefan Monnier
2021-03-29 14:40 ` Gregory Heytings
2021-03-29 15:50 ` Stefan Monnier
2021-03-25 9:09 ` Lars Ingebrigtsen
2021-03-25 10:14 ` Gregory Heytings
2021-03-25 11:00 ` Alan Mackenzie
2021-03-25 2:07 ` Paul W. Rankin via Emacs development discussions.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fa05cc9782c6e2b5deb5@heytings.org \
--to=gregory@heytings.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.