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?