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

[Paul W. Rankin]

> On 25 Mar 2021, at 1:14 am, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> It seems that `font-lock-mode' eventually calls `font-lock-default-function'
>> which calls `font-lock-mode-internal' which sets
>> `font-lock-fontify-buffer-function' to `jit-lock-refontify' (in
>> e.g. emacs-lisp-mode) which would explain what we're seeing?
> 
> These are internal implementation details, which depend also on things
> like `font-lock-support-mode`.
> I was just pointing out that your understanding of the interaction between
> font-lock and the `fontified` property is not right.
> 
> And that's a problem in this discussion because the "expected" behavior
> of `font-lock-fontify-block` and `font-lock-fontify-buffer` (and sadly,
> to a lesser extent also `font-lock-update`) is by and large accidentally
> defined by the implementation rather than by any
> human-level description.

I'm responding to a very narrow issue Gregory raised, which was that yanking a 
defun from an emacs-lisp-mode into a text-mode-buffer, then deactivating 
font-lock-mode did not remove what he considers to be fontification. To me, 
this makes sense because text-mode does not fontify most text, thus any text 
properties on text would not be associated with font-lock and so there's no 
expectation they be removed.

The focus on the fontified property is more for demonstration of why this is 
the case when the action is reversed.

But again, Emacs already has the solution for anyone who finds this unexpected, 
which is the option `yank-excluded-properties'.