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

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Thu, 5 May 2011 22:22:02 UTC

Severity: minor

Tags: notabug

Found in version 24.0.50

Done: Lars Magne Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
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, 06 May 2011 14:20:04 -0300
> > It is about having to extend the refontification area because
> > refontifying a single-line is not sufficient, presumably because the
> > major mode has to handle a multiline font-lock construct.
> 
> The node _says_ it is about what you say up to the comma.  You then
> add "presumably...", which is _not_ part of the node content.

It's just an application of reasoning: is "a single-line is not
sufficient", that must mean that there's more than one line involved.
I added the "presumably" because some user somewhere might decide he
likes to use this hook for something else.

> You seem to be fighting making this text clear.  Please clearly specify
> how and how much the (current) node content is related to multiline
> font-lock constructs.  That's what is missing.

I'm in a bad position to fix it, because AFAICT the text already says
very clearly what the var does, and when it makes sense to use it.
Could you provide a sample patch that would make the text clear to you?


        Stefan




This bug report was last modified 14 years and 27 days ago.

Previous Next


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