Re: emacs rendering comparisson between emacs23 and emacs26.3

[Stefan Monnier]

> I still don't understand why it had to be eliminated.  Defaulting it to
> nil but respecting a non-nil value would have been completely sufficient
> IMHO.

I can answer why it wasn't changed to nil:

1- o-p-i-c-0-i-d-s had an "invisible" effect on `forward-comment`, where
   the only visible effect was that sometimes it caused
   `forward-comment` to misbehave.  This use was just an optimization.
   Setting the var to nil avoided the misbehavior but could result in
   *much* worse performance in some cases (e.g. calling
   `parse-partial-sexp` from `point-min` once per line skipped when
   scanning text backward, so O(N*M) where N is the size of the buffer
   and M is the distance we're moving).  So just changing the var to nil
   was really not an option, it needed to be replaced by *another*
   optimization.  BTW, I still see not reason to link this other
   optimization, which relies on `syntax-ppss` with the scrolling
   performance problems you are seeing, especially if it's only visible
   in CC-mode buffers and not in things like Javascript (which have an
   almost identical syntax-table).

2- o-p-i-c-0-i-d-s also had (and still has) an effect on
   `beginning-of-defun` and this effect is supposed to be visible and
   predictable.  It's not just an optimization.  So changing the var to
   nil would have changed the behavior of `beginning-of-defun` and there
   was a very clear resistance to that.  Another reason not to just
   change its value to nil.

I also can't imagine how defaulting to nil "would have been completely
sufficient IMHO": setting the var to nil had been an option for decades
but it never enjoyed much popularity.


        Stefan