Re: emacs rendering comparisson between emacs23 and emacs26.3

[martin rudalics <rudalics@gmx.at>]

 > I understand proving/disproving it is hard.

We've been through this before.  What made me stumble over it this time
is Bug#40278 where I was not able to reproduce any flickering with the
OP's scenario because here scrolling buffers like dispextern.h and
xdisp.c takes some 10 seconds to complete.  I did not investigate what
precisely makes scrolling so slow.  The shear fact that this happens
exclusively with C buffers is enough evidence for me to point at CC mode
as the major culprit.

Now if we had left in 'open-paren-in-column-0-is-defun-start' and would
still be able to handle its non-nil value in some rudimentary way, with
all the bugs it may cause, we would have at least some evidence at our
hands to say, for example, that "going beyond some open paren is
dangerous in the case at hand" and might allow us to spot some
unrestricted movement in that direction.  But as it is, we have no clue,
no smoking gun, and every evidence about where cc-mode moves to when
analyzing the construct at point must be (re-)constructed in a rather
cumbersome way.

 > I'm really asking what are the signs that make you think it's
 > due to the lack of use of `open-paren-in-column-0-is-defun-start`.

We know that parsing a C buffer from the beginning, using something like
our 'parse-partial-sexp', is straightforward and cannot be responsible
for the scrolling problem I mention above.  So the cause must be in a
backtracking step performed by CC mode, either because something in the
state established by parsing does not allow to fully identify the
construct at where parsing stopped (unlikely IMO) or because scrolling
the buffer did overwrite some important part of the state established by
an earlier parsing step.  Note that I'm only talking about scrolling
such buffers, no buffer modifications that would invalidate an earlier
established state are involved here.

 >> But customizing 'open-paren-in-column-0-is-defun-start' has no effect
 >> here any more and reconstructing its earlier semantics would consume
 >> more resources than I can afford.
 >
 > Yes, I don't think there's much interested in going back to that.
 > OTOH if we could find specific cases where the old code was faster
 > (supposedly due to its use of `open-paren-in-column-0-is-defun-start`),
 > we could think about how to recover that performance.

'open-paren-in-column-0-is-defun-start' was dismounted in many steps
spread over many years.  We know that we can't go back there.

 > E.g. `open-paren-in-column-0-is-defun-start` was used in
 > `forward-comment` was scanning comments backward to avoid having to use
 > `parse-partial-sexp` all the way from `point-min` in the worst case.
 > We replaced that with a parse cache (`syntax-ppss`) which seems to be
 > just as good in my experience (and significantly better in those
 > languages where open parens in column 0 are virtually non-existent).

This goes without saying and is also a good argument in the case of C
header files like dispextern.h where the missing
'open-paren-in-column-0-is-defun-start' can be hardly the cause of the
poor performance.

 > If we can show that this replacement is not "just as good", there are
 > various options to improve it or replace it, but we'd need to know which
 > case(s) matter in order to design it.

'open-paren-in-column-0-is-defun-start' would be one knob to press when
things go wrong in some untraceable way.  It would provide a way to
narrow the current buffer down to the three nearest functions around
point and forget about the rest.  As it is, it has no effect at all.

martin