From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Gregory Heytings <gregory@heytings.org>
Cc: emacs-devel@gnu.org
Subject: Re: master 2399541: Remove font-lock toggle from font-lock-update
Date: Mon, 29 Mar 2021 11:50:29 -0400 [thread overview]
Message-ID: <jwvpmzi3rqq.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <a83bd81e9a8019a68cd9@heytings.org> (Gregory Heytings's message of "Mon, 29 Mar 2021 14:40:19 +0000")
>>> One thing I'm not entirely sure is whether the second case is (and
>>> font-lock-mode (not font-lock-keywords)) or (and font-lock-mode (not
>>> font-lock-fontified)), but my guess is that font-lock-fontified is an
>>> internal variable and that it is safer to use font-lock-keywords here.
>>
>> I'm not entirely sure what is the best way to detect this middle-point
>> either. The code that decides whether to activate the font-lock machinery
>> calls `font-lock-specified-p` for that, but maybe there are corner cases
>> where the machinery can be activated even when `font-lock-specified-p`
>> returns nil? Similarly, I'm not sure if `font-lock-fontified` is always
>> non-nil when the font-lock machinery is activated and always nil when it
>> isn't.
>>
>> IOW, someone needs to look carefully at the code to find out (and
>> presumably then document the result e.g. by adding a function that returns
>> this info, or with comments, or by adding a variable which keeps track of
>> this info or ...).
>>
>
> I guess that Someone^TM is me? ;-) I'll have a look.
BTW, this relates to the distinction between "font-lock-mode, the minor
mode that control whether there is highlighting or not" and
"font-lock-mode, the most common way to apply highlighting when
requested".
Admittedly, it seems the only user of `font-lock-function` (the core
variable that allows taking advantage of this distinction to provide
a different machinery) is `ert.el` which just uses in a marginal way
that could probably be replace by the use of `font-lock-hook` or
something like that.
>>>>> +Otherwise, with prefix ARG, toggle Font Lock mode."
>>>>
>>>> Is this behavior useful?
>>>
>>> I think it is, yes, and I think it makes sense to use the prefix argument
>>> for that. M-x font-lock-mode does not always produce the expected
>>> effect, which can be puzzling, so having a way to "do what I mean" in
>>> a command is useful.
>>
>> Could you describe what you mean by "does not always produce the expected
>> effect" here? [ And maybe how the prefix ARG to `font-lock-dwim` avoids
>> those problems? ]
>>
> By "does not always produce the expected effect", I mean for example that
> M-x font-lock-mode in a text-mode or fundamental-mode buffer does not
> remove then fontification from a piece of code that was killed-yanked from
I see. IIUC, that's unrelated to the:
Otherwise, with prefix ARG, toggle Font Lock mode
part of the command's behavior, right?
Stefan
next prev parent reply other threads:[~2021-03-29 15:50 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
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 [this message]
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=jwvpmzi3rqq.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=gregory@heytings.org \
/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.