GNU bug report logs - #23271
CC Mode 5.33 (C/l); Cache failure

Previous Next

Full log

View this message in rfc822 format

From: Michael Welsh Duggan <mwd <at> md5i.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 23271 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> cert.org>
Subject: bug#23271: CC Mode 5.33 (C/l); Cache failure
Date: Thu, 19 May 2016 22:29:37 -0400

Alan Mackenzie <acm <at> muc.de> writes:

> Hello again, Michael.
>
> On Thu, May 05, 2016 at 03:49:58PM -0400, Michael Welsh Duggan wrote:
>> Alan Mackenzie <acm <at> muc.de> writes:
>
>> > Hello, Michael.
>
>> > On Tue, Apr 26, 2016 at 04:18:50PM -0400, Michael Welsh Duggan wrote:
>> >> Alan Mackenzie <acm <at> muc.de> 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
(md5i <at> md5i.com)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.