bug#8626: 24.0.50; (elisp) Region to Fontify after a Buffer Change - Why a child of Multiline Font Lock?

[Drew Adams]

> > This node says zero about multiline font lock.  No apparent
> > relation between the two.  If there is a relation,
> > then it needs to be pointed out.
>  
> I'm not sure what more you need.  It already says:
> 
>    When a buffer is changed, the region that Font Lock refontifies is
>    by default the smallest sequence of whole lines that spans 
>    the change.
>    While this works well most of the time, sometimes it doesn't---for
>    example, when a change alters the syntactic meaning of text on an
>    earlier line.

What limits the import of this node to multiline font-lock?  Nothing that I can
see.

This text simply says that the refontification is for a set of (presumably
contiguous) whole lines.  One can read between the lines to see that it might
not work well for - among other things - multiline font-lock.  But there is
nothing about the text in this node that limits it to multiline font-lock.

This node is about refontification after buffer changes.  It is not, logically,
a subnode of `Multiline Font Lock Constructs'.

The info here belongs in or under node `Change Hooks', or possibly somewhere
else in the font-lock section of the manual.  You can link to this text from the
multiline font-lock section.

And I suggest adding explicitly, after the last line you quoted, that in
particular this is often the case for multiline font-lock.