Re: 'M-o' ('facemap-keymap') has now been removed until March 10th 2021

["Paul W. Rankin" via "Emacs development discussions." <emacs-devel@gnu.org>]

> On 24 Mar 2021, at 6:01 pm, Gregory Heytings <gregory@heytings.org> wrote:
> 
>>>> No bugs here. Both of these work as expected. I think the issue is you're confused about font-lock-mode and text properties. These are not the same thing. Font-lock-mode is just one way to add text properties to text, so may other functions. Deactivating font-lock-mode does not remove all text properties, only on text with the `(fontified . t)' property. This is why you're seeing what you're seeing.
>>> 
>>> Please explain this to Stefan M, who considers this to be bugs, who would like to deprecate the font-lock-fontify-{buffer,block} commands, and who guided me to write the font-lock-update command.
>> 
>> For sure. If you can, please link me to the lists.gnu.org message?
>> 
> 
> I'm curious how you will explain to the author of font-lock-fontify-buffer that his command has no bugs, when he thinks it has and would like to obsolete it.  The first message is at https://lists.gnu.org/archive/html/emacs-devel/2021-03/msg00581.html .

Thanks for the link. I've looped in Stefan so he can tell me I'm wrong, but...

I think the issue you describe, where yanked text includes previous text properties without font-lock-mode active is expected behaviour. You can control this behaviour with the variable `yank-excluded-properties'. (Eli I'm surprised you didn't use this?)

I think Stefan was commenting on how this behaviour might be unexpected, then separately, also commenting on the messiness of the code in `font-lock-fontify-buffer'. But the messiness of that code does not imply that the way text properties work is a bug.

I'm pretty sure the idea is to have a cleaner version of `font-lock-fontify-buffer' i.e. a duplicate, which is almost what you have.

> By the way, what actual problems do you see in font-lock-update?  Do you see cases where it produces unexpected results?

Just the toggling part. The command is called `font-lock-update' but when font-lock-mode is active and the command is called with ARG, it turns font-lock-mode off. From the docstring I'm not sure if that was your intention? Given this is a default key binding on the Holy ctl-x-map (technically the ctl-x-x-map), it should probably do what it says on the tin.

Here's the same but what I'd consider a cleaner approach:

(defun font-lock-update ()
  "Refontify the accessible portion of the buffer.
Unconditionally activate `font-lock-mode'."
  (interactive)
  (unless font-lock-mode (font-lock-mode 1))
  (save-excursion
    (font-lock-fontify-region (point-min) (point-max))))

Technically this is still a bit misleading because of teh aforementioned `font-lock-dont-widen' variable, but we can't have everything.