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

[Paul W. Rankin]

> Does it?  AFAICS, font-lock-unfontify-region does not "remove _all_ text 
> properties", it uses remove-list-of-text-properties, which "removes _some_ 
> properties from text", namely those of font-lock-mode.

Sure, you're right that it does not remove *all* text properties per se. It 
removes, let's say, "all that it can" which is more than "all that is intended".

In my last mail I was attempting to explain what you're seeing in the second 
issue you described:

> It allows you to toggle font-lock-mode correctly, which M-x font-lock-mode 
> can't do.  Try the following: emacs -Q, unless, M-., M-h, M-w, C-x b RET, M-x 
> text-mode, C-y, M-x font-lock-mode.

This is again correct behaviour. When you yank the defun from an 
emacs-lisp-mode buffer into a text-mode buffer, you're inserting text with 
(most of) its text properties, except for the property `(fontified . t)' 
because within the context of *this* buffer, the text properties have not been 
applied with font-lock-mode and so this would be false and prevent font-lock 
from doing its work.

To see how this works, try the reverse: yank a defun from a text-mode-buffer 
(i.e. no syntax highlighting) into an emacs-lisp-mode buffer with 
font-lock-mode active. Since there is no `(fontified . t)' property you'll see 
font-lock go to work and the yanked text will be fontified.

If you dislike this behaviour that's also fine, there's a user option for that: 
yank-excluded-properties, which you can set to t and have what you expect as 
correct behaviour (which fwiw is what I have it set to).

I hope this clears things up for you. Unless there's any outside objection I'm 
going to fix up the command in master to reflect as pasted above.