[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8626: 24.0.50; (elisp) Region to Fontify after a Buffer Change - Why
From: |
Drew Adams |
Subject: |
bug#8626: 24.0.50; (elisp) Region to Fontify after a Buffer Change - Why a child of Multiline Font Lock? |
Date: |
Fri, 6 May 2011 07:01:25 -0700 |
> > 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.