[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11749: Acknowledgement (24.1; C-mode indentation gives wrong-type-ar
From: |
Alan Mackenzie |
Subject: |
bug#11749: Acknowledgement (24.1; C-mode indentation gives wrong-type-argument error.) |
Date: |
Wed, 10 Oct 2012 20:00:25 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi, Michael,
On Tue, Oct 09, 2012 at 10:05:07AM -0400, Michael Welsh Duggan wrote:
> Alan Mackenzie <acm@muc.de> writes:
[ .... ]
> >> >>> M-x c-toggle-parse-state-debug
> >> >>> It works by calculating c-parse-state twice for each call - The first
> >> >>> time normally, then again with the internal state bound to "newly
> >> >>> initialised". If the the two results differ, they are printed to
> >> >>> *Messages*, together with the saved previous state. If this does
> >> >>> trigger, please note any recent buffer changes. It may make editing
> >> >>> intolerably slow.
> >> >> I will turn this on.
> >> I turned this on, and inserted a (ding) where cc-mode outputs an
> >> inconsistency message. I can barely stand to edit code now, due to
> >> what seem to be almost every key press causing a beep. Have you made
> >> any progress here, or do you need more data?
> > I have found the bug which is causing (most of) these dings, though I
> > don't think it is the one which caused Kim's original bug. Could you try
> > out the patch below, please. (I have also enhanced/corrected the
> > debugging routines a bit, too.)
> Still doesn't seem to help much here. I have attached a file which
> reliably causes a cache failure. I have attached the smallest file of
> the set of files I am working on that causes this particular problem.
> Load the attached file and toggle on parse state debugging. Then scroll
> to the bottom of the file. (Use C-v multiple times, or just M->.) One
> reason I have attached this file is that it only triggers the warning
> message once. Most of my larger files cause this to happen quite a lot.
What is happening in this file is another bug, arising from historical
assumptions which are no longer valid.
The "from scratch" calculation notes that the starting scanning position
would be a long way (>5000) back, hence it tries going back to the second
"beginning-of-defun" to get a top-level starting point. This
"beginning-of-defun" is a pure "brace in column zero" test.
This doesn't work in C++ when constructs inside a namespace have braces
at column zero, something I believe has become very common in recent
years. Namespaces didn't exist in C++ when c-parse-state was originally
written.
Obviously this optimisation is no longer valid. I wouldn't be surprised
if it has caused quite a bit of buggy behaviour. I'll need to think it
over for a few days to decide what to do.
Again, thanks for taking so much trouble in submitting these bug
reports.
> --
> Michael Welsh Duggan
> (mwd@cert.org)
--
Alan Mackenzie (Nuremberg, Germany).