Re: How can I predict which regions xdisp will present me for font-locking?

[John Yates <john@yates-sheets.org>]

On Sun, Mar 11, 2012 at 5:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 11 Mar 2012 20:59:03 +0000
>> From: Alan Mackenzie <acm@muc.de>
>>
>> In a file.hpp, inside a 3355 line macro (I kid you not), I type a single
>> character.  xdisp responds by presenting jit-lock, successively, with
>> four areas to fontify.  (This was determined by
>> trace-function-background on `font-lock-fontify-region').
>>
>> None of these areas starts/stops at the top/bottom of the window.  It is the
>> third area which encloses the changed line.  The fourth area finishes
>> below the window's last line.
>>
>> I can't see how this wierd sequence of fontification areas can be
>> being calculated by CC Mode.
>>
>> This seemingly superfluous fontification seems to be causing a
>> performance degradation.
>>
>> How can this series of fontification regions be explained?
>
> I think what happens is this:
>
>  . every change in the buffer triggers a call to
>    font-lock-extend-jit-lock-region-after-change (via
>    jit-lock-after-change-extend-region-functions)
>
>  . font-lock-extend-jit-lock-region-after-change extends the region
>    of the change according to the font-lock properties of the major
>    mode, then marks that region unfontified by putting on it a
>    `fontified' text property with the value nil
>
>  . the next redisplay cycle calls jit-lock-function (via
>    fontification-functions) at the beginning of the region whose
>    `fontified' property is nil, and refontifies the region from there
>    in chunks of 500 characters (but every chunk is extended so that
>    its start is at the beginning of a line and its end is at the end
>    of a line)
>
> Does this explain what you see?

How does this strategy differ from 23.x?

I am seeing a horrendous slowdown when editing atypical macros (though
no more than 50 lines long).  Worse still I see the same slowdown when
editing a comment if even a fragment of my atypical macro is visible.

The pattern of the macro is

#define LIST_NAME \
  _ROW_( <literal columns> ) \
, _ROW_( <literal columns> ) \
... \
, _ROW_( <literal columns> ) \

/john