bug#61215: 29.0.60; font-lock broken in diff-mode with long lines

[Juri Linkov]

>>> 1. (setq debug-on-error t backtrace-on-redisplay-error t)
>>> 2. Create a commit with some diff hunks in a prog mode at the beginning, 
>>> and a single-line 1MB file added at the end;
>>> 3. From *vc-change-log* type `d' on that commit that opens *vc-diff* buffer
>>> 4. Scroll the *vc-diff* buffer
>>>
>>> It displays an error in the *Warning* buffer:
>>>
>>>  ⛔ Warning (error): Error in a redisplay Lisp hook.  See buffer 
>>> *Redisplay_trace*
>>
>> I did, in the Emacs repository:
>>
>> echo README >> README
>> echo CONTRIBUTE >> CONTRIBUTE
>> echo INSTALL >> INSTALL
>
> Actually, these files can't expose the problem.
> I suggest to use a mode with complex font-lock rules
> for syntax highlighting.  I tested with a few of 1-char edits
> in a few places inside an .el file.
>
>> git add a.xml
>
> The diff will output the file name a.xml at the beginning, but
> better to output it after the file with changes.  The complete
> diff output should look like this: first a few diff hunks
> each with 1-line change from an .el file with syntax fontification.
> Then at the end of the screen the huge file added in the same commit.
>
>> git commit -a -m commit
>> ./src/emacs -Q --eval '(setq debug-on-error t backtrace-on-redisplay-error 
>> t)'
>> C-x v l
>> d
>
> Not sure if this shows diffs only from one file.
> More reliable would be to use 'C-x v L d'
> to show a multi-file commit.
>
>> At that point there are no errors, and the a.xml hunk is correctly
>> fontified.  Now if I do:
>>
>> q
>> d
>>
>> then the errors you mention above appear (and the a.xml hunk is not
>> correctly fontified anymore).  If I manually kill the *vc-diff* buffer,
>> they disappear again.  Is this also what you see?
>
> Hmm, I tried again, and can't reproduce it in emacs-29.
> But in master there are still the same errors.
> How this is possible when emacs-29 is merged to master?

After boostrap errors appear in emacs-29 too.