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

[Paul W. Rankin]

> 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.