bug#16081: Subject: c++-mode indentation "*wedging*"

[Alan Mackenzie]

Hello, Craig.

Craig Steury <craigrsteury@yahoo.com> wrote:
> Hello, this is bug-report is concerned with indentation in
> c++-mode. The symptoms are after some unspecified amount of time/work
> indentation becomes "wedged".

> Here is an example: (the 'get_type()' method below).

> ??? virtual void set_color(const QColor&);
> ??? virtual void set_highlight_color(const QColor&);
> virtual emat_pipe_obj_type_enum get_type();

> No amount of hitting tab-keys, praying, cursing will indent this
> properly.? If I kill the buffer and bring it back it will indent
> properly.? This got irritating enough that I found a thread that
> described a way to provide debugging information to the author of this
> mode.? It said:
> ?;; This should hopefully catch the problem right when it shows up and log
> ?;; some debug info in your *Messages* buffer, which you can then send via
> ?;; M-x report-emacs-bug.
> ?;; OR
> ?;;? To submit a problem report, enter `C-c C-b' from a
> ?;;? c++-mode buffer. 
> ?(setq c-debug-parse-state t)??? ??? ??? ??? ??? ???? ;debug c++-mode 
> indentation problems?

> I've done this and reproduced this problem in a relatively 'clean' emacs
> session.? I've included a copy of the *Messages* buffer below (please
> search for:)? 

Excellent!

> Thanks and I hope this helps!

See below.

> Craig Steury??? 


> In GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
> ?of 2013-03-17 on MARVIN
> Windowing system distributor `Microsoft Corp.', version 6.1.7601

[ .... ]

> *---- Begin Output of *Messages* buffer

> (setq c-state-cache '(1262 1233 1028 (773 . 936) 564 (275 . 481))? 
> c-state-cache-good-pos 1263? c-state-nonlit-pos-cache '(3001)? 
> c-state-nonlit-pos-cache-limit 1? c-state-semi-nonlit-pos-cache nil? 
> c-state-semi-nonlit-pos-cache-limit 1? c-state-brace-pair-desert '(1 . 275)? 
> 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 
> nil? c-state-old-cpp-end nil? c-parse-state-point 1282)
> c-parse-state inconsistency at 1263: using cache: (1262 1233 1028 (773 . 936) 
> 564 (275 . 481)), from scratch: nil
> Old state:
> (setq c-state-cache '(1262 1233 1028 (773 . 936) 564 (275 . 481))? 
> c-state-cache-good-pos 1263? c-state-nonlit-pos-cache '(3001)? 
> c-state-nonlit-pos-cache-limit 1? c-state-semi-nonlit-pos-cache nil? 
> c-state-semi-nonlit-pos-cache-limit 1? c-state-brace-pair-desert '(1 . 275)? 
> 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 
> nil? c-state-old-cpp-end nil? c-parse-state-point 1282)
> c-parse-state inconsistency at 1285: using cache: (1262 1233 1028 (773 . 936) 
> 564 (275 . 481)), from scratch: nil
> Old state:
> (setq c-state-cache '(1262 1233 1028 (773 . 936) 564 (275 . 481))? 
> c-state-cache-good-pos 1263? c-state-nonlit-pos-cache '(3001)? 
> c-state-nonlit-pos-cache-limit 1? c-state-semi-nonlit-pos-cache nil? 
> c-state-semi-nonlit-pos-cache-limit 1? c-state-brace-pair-desert '(1 . 275)? 
> 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 
> nil? c-state-old-cpp-end nil? c-parse-state-point 1263)

Unfortunately, the first line of the first entry ("c-parse-state
inconsistency at L....") has been lost here.  Could it be that this
wasn't the first inconsistency, but the *Messages* buffer has overflowed?
In this case it can be helpful to set the variable `message-log-max' to t.
Only the first report of inconsistency is really useful, since it indicates
the point where an internal cache may have become corrupted.

To use this debug information, I need the C++ source file.  Is there any
chance you could post this?  (Or alternatively, send it to me privately.)
The debug output suggests this file may be quite small.  Also, please
report explicitly whether or not you were changing the buffer at the time
the inconsistency was reported, and if so, how.

There's just one thing I'll ask you to try first: there's a known bug
triggered by having an open parenthesis/brace/bracket at column 0 inside a
comment.  Would you please check your code for this, and if you find such
a paren/br/br try removing it to see if the bug then goes away.

So, quick summary: please check for that open p/b/b in column 0.  If not
found then post (or mail to me) the source file and the very first two
"inconsistency" reports, together with details on whether the buffer was
being changed.

Thanks for taking the trouble to report this.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).