emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 2399541: Remove font-lock toggle from font-lock-update


From: Stefan Monnier
Subject: Re: master 2399541: Remove font-lock toggle from font-lock-update
Date: Thu, 25 Mar 2021 09:52:54 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> Hmmm...  You said: "`font-lock-fontify-region` is an important function
> internally (it's the one and only function which performs font-locking,
> fundamentally)".  Is it wrong to use it nonetheless?

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.
[ Tho maybe I'd prefer if it used `font-lock-flush` or
  `font-lock-ensure`.  ]

>> 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.  The rest is more
"obvious" (like whether it should pay attention to an active region, or
only refresh the visible portion of the buffer, ...).

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.

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.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]