bug#74281: 30.0.91; font-lock mode hangs on scrolling large Scheme file

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> diff --git a/lisp/progmodes/scheme.el b/lisp/progmodes/scheme.el
>> index a0f922f279c..c46422b7218 100644
>> --- a/lisp/progmodes/scheme.el
>> +++ b/lisp/progmodes/scheme.el
>> @@ -201,7 +201,10 @@ scheme-mode-variables
>>             scheme-font-lock-keywords-1 scheme-font-lock-keywords-2)
>>            nil t (("+-*/.<>=!?$%_&~^:" . "w") (?#. "w 14"))
>>            beginning-of-defun
>> -          (font-lock-mark-block-function . mark-defun)))
>> +          (font-lock-mark-block-function . mark-defun)
>> +          ;; The (?#. "w 14") above causes font-lock to incorrectly
>> +          ;; set `font-lock--syntax-table-affects-ppss' to t.
>> +          (font-lock--syntax-table-affects-ppss . nil)))
>>    (setq-local prettify-symbols-alist lisp-prettify-symbols-alist)
>>    (setq-local lisp-doc-string-elt-property 'scheme-doc-string-elt))
>
> What does it do,

This variable controls whether font-lock uses `syntax-ppss` or not.
By setting to nil, it lets font-lock use `syntax-ppss` which means that
on large buffers it tends to be much faster because it doesn't need to
`parse-partial-sexp` all the way from `point-min` every time.

> and what potential harm could happen if we install this?

If it's set incorrectly, it can lead to messed up `syntax-ppss` state
(because some calls use one syntax table and others use another) which
could lead to mis-indentation, mis-fontification, incorrect highlighting
of matched paren, incorrect buffer navigation, etc...
Of course, these risks are confined to those buffers that use
`scheme-mode` or a mode that derives from it.

I believe the setting is correct for `scheme-mode`, but it's possible
that some derived mode changes the `font-lock-syntax-table` and relies
(incorrectly) on `scheme-mode` having already set
`font-lock--syntax-table-affects-ppss` to t.

This said, AFAICT this performance problem has been with us since
Emacs-28 (commit cdadb7a97cbe), so it's not super urgent to fix it.
I think we're fine with the fix on `master`.  It would be nice
to get confirmation from Divya that it does fix the problem he sees.


        Stefan