[Top][All Lists]

[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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]