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

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 8626 <at> debbugs.gnu.org
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.