unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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


  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).