GNU bug report logs -
#18749
24.3.94; CC Mode 5.32.5 (C/l); cc-mode state cache failure leading to bad indentation
Previous Next
Reported by: Michael Welsh Duggan <mwd <at> md5i.com>
Date: Thu, 16 Oct 2014 21:14:02 UTC
Severity: normal
Found in version 24.3.94
Done: Alan Mackenzie <acm <at> muc.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Hello, Michael.
It's been a fun day. ;-)
In article <87h9z367nq.fsf <at> maru2.md5i.com> you wrote:
> [-- text/plain, encoding 7bit, charset: US-ASCII, 6 lines --]
> A consistent c-mode indentation error that causes bad indentation, much
> cursing, and gnashing of teeth. This occurs in the latest emacs-24
> branch (and trunk).
> From emacs -Q, using the attached file:
> [-- text/plain, encoding 7bit, charset: US-ASCII, 2434 lines, name: rwuniqsetup.c.before.2 --]
[ .... ]
> [-- text/plain, encoding quoted-printable, charset: utf-8, 291 lines --]
> M-x c-toggle-parse-state-debug
> C-x C-f rwuniqsetup.c.before.2
> C-s ipaddr_rec_to_bin RET
> C-v
> At this point you should see the following in *Messages*:
[ The following has been altered from the original to show the correct
first inconsistency which occurred.]
> Mark saved where search started
> c-parse-state inconsistency at 46719: using cache: ((46217 . 46572) 45454 (43406 . 45002)), from scratch: (45454 (43406 . 45002))
> Old state:
> (setq c-state-cache '((46217 . 46572) 45454 (43406 . 45002)) c-state-cache-good-pos 46747 c-state-nonlit-pos-cache '(76939 73939 70939 67939 64939 61939 58939 55939 52939 49939 46939 43114 39291 36291 33291 30291 27178 24178 21178 18178 15145 12046 9013 6002 3002) c-state-nonlit-pos-cache-limit 76939 c-state-semi-nonlit-pos-cache '(45291 42291 39291 36291 33291 30291 27094 24058 21058 18058 15058 12046 9013 6001 3001) c-state-semi-nonlit-pos-cache-limit 45291 c-state-brace-pair-desert '(1 . 45935) c-state-point-min 1 c-state-point-min-lit-type nil c-state-point-min-lit-start nil c-state-min-scan-pos 1 c-state-old-cpp-beg #<marker at 45006 in rwuniqsetup.c.before.2> c-state-old-cpp-end #<marker at 46938 in rwuniqsetup.c.before.2> c-parse-state-point 46793)
> At this point, indentation is having problems. Try hitting TAB on line
> 1371, for example. Or line 1374 for a complete failure to indent at
> all.
OK, for once c-parse-state seems to be blameless.
What seems to be happening is that during the display fontification,
operations are done at buffer offset 46793. This is the spot after the
indentation on L1360.
CC Mode puts a backwards search limit on many operations, and this is
often implemented by temporarily narrowing the buffer (narrow-to-region
(- (point) n) (point-max)), where n is sometimes 1000.
1000 bytes before 46793 is 45793. This spot is in the middle of the "##"
operator on L1346. Thus the buffer is getting narrowed such that the
first character, ostensibly at BOL (to the Emacs regexp matcher), is "#".
A `c-beginning-of-macro' operation is thus spuriously finding point
45793, in the middle of this operator. This spot is then getting
permanently marked as a beginning-of-CPP. (Technically, this is done
with the 'category property, giving it a value 'c-cpp-delimiter.)
When c-parse-state later tries to scan this part of the code, it trips up
on this spurious beginning-of-CPP, terminating its scanning. If you look
at the two inconsistent values for c-parse-state above, the "from
scratch" value is actually the false one, where it fails to find the
brace pair (46217 . 46572) which is after 45793.
I think what I'm going to do is insert an extra check into
c-beginning-of-macro, such that if there seems to be a match at
(point-min) of a narrowed buffer (or possibly even on the top line of
one), it will be widened and tested again.
Look forward to a patch soon!
> --
> Michael Welsh Duggan
> (md5i <at> md5i.com)
--
Alan Mackenzie (Nuremberg, Germany).
This bug report was last modified 9 years and 154 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.