[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
bug#8626: 24.0.50; (elisp) Region to Fontify after a Buffer Change - Why a child of Multiline Font Lock?
Fri, 06 May 2011 14:20:04 -0300
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
> > 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?