bug#16526: 24.3.50; scroll-conservatively & c-mode regression

[Alan Mackenzie <acm@muc.de>]

Hi, Martin.

On Mon, Jan 27, 2014 at 09:21:24AM +0100, martin rudalics wrote:
>  > The @dfn{state cache}, a list of certain brace/paren/bracket positions
>  > around some position, is set for a position near EOB.  With the switch to
>  > a different position, CC Mode tweaks the state cache rather than
>  > calculating it anew starting at BOB.  When the new position is nearer
>  > BOB, the code searches backwards for the appropriate braces.  However, it
>  > shouldn't be scanning the entire buffer backwards.  There is clearly a
>  > bug here.

> In my scenario `end-of-buffer' should already have produced the complete
> state cache.  How else would you have been able to fontify code near EOB
> correctly?

The state cache contains not only a list of enclosing
braces/brackets/parentheses but also any brace pair immediately
preceding one of these things.  So a typical state cache looks like:

    (4532 (4284 . 4526) 4278 (4131 . 4248))

(with a detailed explanation in cc-engine.el in the comment for
`c-parse-state-1').

When c-parse-state is called at a position somewhat distant from the
previous call, it modifies the state cache by crawling through the
buffer rather than recalculating it from scratch.

>  > The backward scan-lists calls will be causing continual forward searches
>  > from BOB in syntax.c, every time the backward scan hits a comment ender.

> IIUC now any call to `forward-comment' with a negative argument will
> automatically go to BOB unless it's already there.  How else could it
> determine that it's not called from a position within a comment?

I don't think this happens.  back_comment (in syntax.c) assumes it
starts outside a comment.

> So if you decide to bind `open-paren-in-column-0-is-defun-start' to
> nil, then why don't you build the state cache anew from BOB?
 
The state cache has different values for different buffer positions.

> In any case, please provide an option say
> `c-open-paren-in-column-0-is-defun-start' which people can set to
> avoid those scans.  The doc-string should mention that things like
> Michael's commented out code are handled correctly iff this option is
> nil and that long delays while working with c-mode can be sometimes
> avoided by setting this option to t.  The default value could be
> obviously nil.
 
I'm hoping that the (rough) patch in one of my other emails from this
evening will have solved the bug, so that playing around with
open-paren-in-column-0-etc. won't be needed.

As a matter of interest, with my patch applied, running your recipe on
xdisp.c took me 4.4 seconds (including the (sit-for 3)).

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).