Subject: bug#23271: CC Mode 5.33 (C/l); Cache failure

From: Michael Welsh Duggan <[email-masked]>
Date: Thu, 19 May 2016 22:29:37 -0400

Alan Mackenzie <[email-masked]> writes:

> Hello again, Michael.
>
> On Thu, May 05, 2016 at 03:49:58PM -0400, Michael Welsh Duggan wrote:
>> Alan Mackenzie <[email-masked]> writes:
>
>> > Hello, Michael.
>
>> > On Tue, Apr 26, 2016 at 04:18:50PM -0400, Michael Welsh Duggan wrote:
>> >> Alan Mackenzie <[email-masked]> writes:
>
> [ .... ]
>
>> > I think the issue here is `open-paren-in-column-0-is-defun-start'.  In
>
>> >>> c-parse-state inconsistency at 33929: using cache: (33928 33838
>> >>> (32429 . 33731) 795 365), from scratch: (33928 33838 (32429
>> >>> . 33731))
>
>> > , the brace pair (32429 . 33731)'s opener at 32429 is in column zero.
>> > So, if `open-paren-...-start' is non-nil, the low level syntax routines
>> > aren't going to be scanning back any further than that.  I think, in
>> > this case, the braces at 365 and 795 got into the cache early on, and
>> > stayed there.
>
>> > Would you check your setting of that variable, please, and if it's
>> > non-nil, try setting it to nil to see if the inconsistency goes away.
>> > If it's already nil, please let me know, in which case I've got some
>> > serious head scratching to do.
>
>> This occurs with a nil setting of
>> `open-paren-in-column-0-is-defun-start'.  It was nil when I submitted
>> the original bug report.  (You might want to add this variable to the
>> c-submit-bug-report report.)
>
>> Apologies in advance for any hair loss.  :)
>
> Sorry to be persistent, but can we please be absolutely sure about this.
> open-paren-in-column-0-is-defun-start is t by default.  In your original
> bug recipe, you don't mention setting that variable to nil.
>
> It's just that with the default setting of o-p-i-column-0-i-d-start, I
> can reproduce your exact results.

I can confirm that if I modify the original recipe to include
(setq-default open-paren-in-column-0-is-defun-start nil) before loading
the file, it still errors out, and the output of `C-h v
open-paren-in-column-0-is-defun-start' is:

open-paren-in-column-0-is-defun-start is a variable defined in ‘C source code’.
Its value is nil
Original value was t

>> I tried it on a different machine with the same frame width (but
>> different frame height), and got the included output after 8 page-downs.
>> The last full line on the first page is:
>
>>    * <li>the graph is bidirectional ("bidrectionalS" as the third
>> template argument),</li>
>
>> I hope this differing output helps you track down the problem.
>
> I think this is something different.  I can't reproduce it at the moment,
> but I'll keep trying.  The source line is line 53.  So the number of
> lines scrolled per C-v must be ~6.  With next-screen-context-lines at its
> default of 2, that suggests a window 8 lines high, not counting wrapped
> lines.  With (...'((height .11))), I can count 9 C-v's before L53 becomes
> the bottom line.  But I don't get the inconsistency.  I'll keep trying.

I'll try again when I am on that machine again (tomorrow).

-- 
Michael Welsh Duggan
([email-masked])