Reported by: Michael Welsh Duggan <mwd <at> cert.org>
Date: Tue, 20 Sep 2011 15:31:01 UTC
Severity: normal
Found in version 24.0.50
Done: Alan Mackenzie <acm <at> muc.de>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9560 in the body.
You can then email your comments to 9560 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#9560; Package emacs.
(Tue, 20 Sep 2011 15:31:01 GMT) Full text and rfc822 format available.Michael Welsh Duggan <mwd <at> cert.org>:bug-gnu-emacs <at> gnu.org.
(Tue, 20 Sep 2011 15:31:01 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Michael Welsh Duggan <mwd <at> cert.org> To: bug-gnu-emacs <at> gnu.org Subject: 24.0.50; c-mode syntax problems Date: Tue, 20 Sep 2011 11:25:08 -0400
I really wish I could give an exact recipe for this, but this particular
failure is extremely transient. I can leave an emacs open in an bad
state for postmortem diagnosis, but I cannot predict when or under what
conditions this problem and ones similar to it will happen.
In this particular case, I am editing an immediate struct at top level.
For example:
static const sk_stringmap_entry_t field_map_entries[] = {
{"class", RWST_CLASS, "class name", NULL},
{"type", RWST_TYPE, "type name", NULL},
{"flowtype", RWST_FLOWTYPE, "flowtype name", NULL},
{"id-flowtype", RWST_FLOWTYPE_ID, "flowtype integer identifier", NULL},
{"sensor", RWST_SENSOR, "sensor name", NULL},
{"id-sensor", RWST_SENSOR_ID, "sensor integer identifier", NULL},
{"describe-sensor", RWST_SENSOR_DESC, "sensor description", NULL},
{"default-class", RWST_DEFAULT_CLASS, "default class name", NULL},
{"default-type", RWST_DEFAULT_TYPE, "default type name", NULL},
{"mark-defaults", RWST_MARK_DEFAULTS,
"'+' for default classes, '*' for types", NULL},
{"class:list", RWST_CLASS_LIST, "list of class names", NULL},
{"type:list", RWST_TYPE_LIST, "list of type names", NULL},
{"flowtype:list", RWST_FLOWTYPE_LIST, "list of flowtype names", NULL},
{"id-flowtype:list", RWST_FLOWTYPE_ID_LIST,
"list of flowtype integer identifier", NULL},
{"sensor:list", RWST_SENSOR, "list of sensor names", NULL},
{"id-sensor:list", RWST_SENSOR_ID,
"list of sensor integer identifier", NULL},
{"default-class:list", RWST_DEFAULT_CLASS_LIST,
"list of default class name", NULL},
{"default-type:list", RWST_DEFAULT_TYPE_LIST,
"list of default type name", NULL},
};
Note the indentation of that next-to-last line. That's because the
syntax thinks it is ((statement-block-intro 4740) (statement-cont
4740)), indent: 12. It thinks the line above it is ((defun-open 4740)),
indent: 4. But if I cursor up a few lines before hitting TAB, I get
((brace-list-entry 4557)), indent: 5, and tabbing down from there fixes
the problem. This has happened to me three times while adding entries
to this struct. I will include the entire file as I am editing it in
this bug report, in case someone can recreate it by emptying the struct
and typing the stuff in again.
This sort of problem happens to me relatively frequently when editing C
files, on the order of 1-10 times a day. Usually saving and reloading
the file fixes the problem. Sometimes reindenting the section does. If
there is any in-situ debugging I can do when this happens again, please
let me know.
auto-fill-mode (setq
c-basic-offset 4
c-comment-only-line-offset '(0 . 0)
c-indent-comment-alist '((anchored-comment column . 0) (end-block space . 1)
(cpp-end-block space . 2))
c-indent-comments-syntactically-p nil
c-block-comment-prefix "* "
c-comment-prefix-regexp '((pike-mode . "//+!?\\|\\**") (awk-mode . "#+")
(other . "//+\\|\\**"))
c-doc-comment-style '((java-mode . javadoc) (pike-mode . autodoc)
(c-mode . gtkdoc))
c-cleanup-list '(scope-operator)
c-hanging-braces-alist '((substatement-open before after)
(arglist-cont-nonempty))
c-hanging-colons-alist nil
c-hanging-semi&comma-criteria '(c-semi&comma-inside-parenlist)
c-backslash-column 48
c-backslash-max-column 72
c-special-indent-hook '(c-gnu-impose-minimum)
c-label-minimum-indentation 1
c-offsets-alist '((inexpr-class . +)
(inexpr-statement . +)
(lambda-intro-cont . +)
(inlambda . c-lineup-inexpr-block)
(template-args-cont c-lineup-template-args +)
(incomposition . +)
(inmodule . +)
(innamespace . +)
(inextern-lang . +)
(composition-close . 0)
(module-close . 0)
(namespace-close . 0)
(extern-lang-close . 0)
(composition-open . 0)
(module-open . 0)
(namespace-open . 0)
(extern-lang-open . 0)
(objc-method-call-cont
c-lineup-ObjC-method-call-colons
c-lineup-ObjC-method-call
+
)
(objc-method-args-cont . c-lineup-ObjC-method-args)
(objc-method-intro . [0])
(friend . 0)
(cpp-define-intro c-lineup-cpp-define +)
(cpp-macro-cont . +)
(cpp-macro . [0])
(inclass . +)
(stream-op . c-lineup-streamop)
(arglist-cont-nonempty
c-lineup-gcc-asm-reg
c-lineup-arglist
)
(arglist-cont c-lineup-gcc-asm-reg 0)
(comment-intro
c-lineup-knr-region-comment
c-lineup-comment
)
(catch-clause . 0)
(else-clause . 0)
(do-while-closure . 0)
(access-label . -)
(case-label . *)
(substatement . +)
(statement-case-intro . *)
(statement . 0)
(brace-entry-open . 0)
(brace-list-entry . 0)
(brace-list-intro . +)
(brace-list-close . 0)
(block-close . 0)
(block-open . 0)
(inher-cont . c-lineup-multi-inher)
(inher-intro . +)
(member-init-cont . c-lineup-multi-inher)
(member-init-intro . +)
(annotation-var-cont . +)
(annotation-top-cont . 0)
(topmost-intro . 0)
(knr-argdecl . 0)
(func-decl-cont . +)
(inline-close . 0)
(class-close . 0)
(class-open . 0)
(defun-block-intro . +)
(defun-close . 0)
(defun-open . 0)
(c . c-lineup-C-comments)
(string . c-lineup-dont-change)
(topmost-intro-cont
first
c-lineup-topmost-intro-cont
c-lineup-gnu-DEFUN-intro-cont
)
(brace-list-open . +)
(inline-open . 0)
(arglist-close . c-lineup-arglist)
(arglist-intro . +)
(statement-cont . c-lineup-math)
(statement-case-open . *)
(label . *)
(substatement-label . 0)
(substatement-open . 0)
(knr-argdecl-intro . 5)
(statement-block-intro . +)
)
c-buffer-is-cc-mode 'c-mode
c-tab-always-indent t
c-syntactic-indentation t
c-syntactic-indentation-in-macros t
c-ignore-auto-fill '(string cpp code)
c-auto-align-backslashes t
c-backspace-function 'backward-delete-char-untabify
c-delete-function 'delete-char
c-electric-pound-behavior nil
c-default-style '((java-mode . "java") (awk-mode . "awk") (other . "gnu"))
c-enable-xemacs-performance-kludge-p nil
c-old-style-variable-behavior nil
defun-prompt-regexp nil
tab-width 8
comment-column 32
parse-sexp-ignore-comments t
parse-sexp-lookup-properties t
auto-fill-function nil
comment-multi-line t
comment-start-skip "\\(//+\\|/\\*+\\)\\s *"
fill-prefix nil
fill-column 70
paragraph-start "[ ]*\\(//+\\|\\**\\)[ ]*$\\|^\f"
adaptive-fill-mode t
adaptive-fill-regexp "[ ]*\\(//+\\|\\**\\)[ ]*\\([ ]*\\([-–!|#%;>*·•‣⁃◦]+[ ]*\\)*\\)"
)
Package: CC Mode 5.31.8 (C/l)
Buffer Style: gnu
c-emacs-features: (pps-extended-state col-0-paren posix-char-classes gen-string-delim gen-comment-delim syntax-properties 1-bit)
In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.4)
of 2011-09-19 on waterbuck.yellow.cert.org
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure '--prefix=/home/mwd' '--without-toolkit-scroll-bars' '--with-gif=no''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=none
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: C/l
Minor modes in effect:
flyspell-mode: t
shell-dirtrack-mode: t
display-time-mode: t
diff-auto-refine-mode: t
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
abbrev-mode: t
Recent messages:
Reading active file via nndraft...done
Checking new news...done
Don't touch it! It's the History Eraser Button, you fool!
syntax: ((brace-list-entry 4646)), indent: 5
syntax: ((statement-block-intro 4740) (statement-cont 4740)), indent: 12
Don't touch it! It's the History Eraser Button, you fool!
Type C-x 1 to remove help window.
Type "q" in help window to restore its previous buffer.
Auto-saving...
syntax: ((statement-block-intro 4740) (statement-cont 4740)), indent: 12
Features:
(shadow emacsbug apropos align time-stamp tabify whitespace dabbrev
help-mode view vc-svn cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs browse-url mule-util
mailalias copyright cus-edit cus-start cus-load sendmail flyspell ispell
sort ansi-color gnus-cite mail-extr qp gnus-async gnus-bcklg gnus-ml
gnus-topic nndraft nnmh utf-7 rot13 disp-table epa-file epa derived epg
network-stream starttls nnimap parse-time tls utf7 netrc gnus-agent
gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu
mml2015 epg-config mm-view mml-smime mailcap gnus-cache edmacro kmacro
nnir gnus-sum gnus-demon nntp gnus-group gnus-undo nnmail mail-source
nnoo gnutls gnus-start gnus-spec gnus-int gnus-range gnus-win gnus-load
woman man uniquify warnings tramp tramp-compat auth-source eieio
byte-opt bytecomp byte-compile cconv macroexp assoc shell pcomplete
tramp-loaddefs time smime password-cache dig comint server psvn advice
help-fns advice-preload cl log-edit ring pcvs-util add-log diff-mode
easy-mmode pgg pgg-parse pgg-def message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader gnus gnus-ems nnheader
gnus-util time-date mail-utils mm-util mail-prsvr wid-edit generic-x
dired-x easymenu dired regexp-opt tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)
--
Michael Welsh Duggan
(mwd <at> cert.org)
bug-gnu-emacs <at> gnu.org:bug#9560; Package emacs.
(Tue, 20 Sep 2011 15:40:02 GMT) Full text and rfc822 format available.Message #8 received at 9560 <at> debbugs.gnu.org (full text, mbox):
From: Michael Welsh Duggan <mwd <at> cert.org> To: "9560\@debbugs.gnu.org" <9560 <at> debbugs.gnu.org> Subject: Re: bug#9560: Acknowledgement (24.0.50; c-mode syntax problems) Date: Tue, 20 Sep 2011 11:34:43 -0400
[Message part 1 (text/plain, inline)]
I forgot to include the file:
[rwsiteinfo.c (text/plain, attachment)]
[Message part 3 (text/plain, inline)]
-- Michael Welsh Duggan (mwd <at> cert.org)
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org:bug#9560; Package emacs,cc-mode.
(Sun, 02 Oct 2011 18:26:01 GMT) Full text and rfc822 format available.Message #11 received at 9560 <at> debbugs.gnu.org (full text, mbox):
From: Michael Welsh Duggan <md5i <at> md5i.com> To: 9560 <at> debbugs.gnu.org Subject: A dribble file of an emacs -Q session that triggers the problem Date: Sun, 02 Oct 2011 14:24:09 -0400
[Message part 1 (text/plain, inline)]
I've managed to trigger this bug in a hopefully repeatable way. I say hopefully because I don't know right now how to replay a dribble file. At any rate, here is what I have: From emacs -Q, I loaded the following file:
[rwsiteinfo-backup.c (text/x-csrc, attachment)]
[Message part 3 (text/plain, inline)]
After loading the file, I started a dribble file as follows: M-x open-dribble-file RET /tmp/c-mode-debug.dribble RET I then started editing the file until I encountered the syntax problem. Near the end of the dribble file, after I encounter the problem, I end up messing around a bit with turning on the echoing of syntactic information, and it takes a while for me to get it right. Please be warned, that my exiting emacs afterward is contained within the dribble file, so you may want to remove those characters before replaying it. Here is the dribble file in question:
[c-mode-debug.dribble (application/octet-stream, attachment)]
[Message part 5 (text/plain, inline)]
I am hoping that my typing sequence is enough to replicate the problem, and that timing doesn't play any part. Hope this helps. -- Michael Welsh Duggan (md5i <at> md5i.com)
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org:bug#9560; Package emacs,cc-mode.
(Mon, 10 Oct 2011 04:16:01 GMT) Full text and rfc822 format available.Message #14 received at 9560 <at> debbugs.gnu.org (full text, mbox):
From: Michael Welsh Duggan <md5i <at> md5i.com> To: 9560 <at> debbugs.gnu.org Subject: Cache information during failure Date: Mon, 10 Oct 2011 00:15:04 -0400
[Message part 1 (text/plain, inline)]
I tried recreating the problem again, successfully. This time, I evaluated the c-state-dump function in the comments in cc-engine. Here is that state data, and the file at that point: "(setq c-state-cache '(4054 (3986 . 4048))) (setq c-state-cache-good-pos 4055) (setq c-state-nonlit-pos-cache 'nil) (setq c-state-nonlit-pos-cache-limit 3497) (setq c-state-brace-pair-desert '(3495 . 3986)) (setq c-state-point-min 1) (setq c-state-point-min-lit-type nil) (setq c-state-point-min-lit-start nil) (setq c-state-min-scan-pos 1) (setq c-state-old-cpp-beg nil) (setq c-state-old-cpp-end nil) "
[rwsiteinfo-backup.c (text/x-csrc, attachment)]
[Message part 3 (text/plain, inline)]
-- Michael Welsh Duggan (md5i <at> md5i.com)
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org:bug#9560; Package emacs,cc-mode.
(Thu, 13 Oct 2011 02:34:02 GMT) Full text and rfc822 format available.Message #17 received at 9560 <at> debbugs.gnu.org (full text, mbox):
From: Michael Welsh Duggan <md5i <at> md5i.com> To: 9560 <at> debbugs.gnu.org Subject: An exact recipe Date: Wed, 12 Oct 2011 22:33:22 -0400
[Message part 1 (text/plain, inline)]
From emacs -Q: Do NOT resize the frame. The recipe includes C-v, which depends on the window (and hence frame) size. Load the following file:
[rwsiteinfo-backup.c (text/x-csrc, attachment)]
[Message part 3 (text/plain, inline)]
Type: M-x edit-kbd-macro RET y C-x e C-x h C-w C-x i When prompted, insert the following keyboard macro file:
[c-mode.macro (application/octet-stream, attachment)]
[Message part 5 (text/plain, inline)]
Type: C-c C-c You should be back at rwsiteinfo-backup.c. Execute the macro using: C-x e Then type: TAB At this point, you should see the indentation move to just under the `o' in "flowtype:list". This location is incorrect. If you then do the following: M-x set-variable RET c-echo-syntactic-information-p RET t RET TAB you will see that c-mode believes the syntax at that point to be topmost-intro-cont instead of the proper brace-list-entry. When you have solved this bug, please let me know if the solution has a reasonable chance of having solved the other problem that I have not been able to recreate reliably, which is getting "topmost-intro indent 0" instead of "statement indent 4" when in the middle of editing a function. If these have little chance of being connected, I'll do my best to try to create that scenario again (no promises). -- Michael Welsh Duggan (md5i <at> md5i.com)
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org:bug#9560; Package emacs,cc-mode.
(Wed, 19 Oct 2011 10:23:01 GMT) Full text and rfc822 format available.Message #20 received at 9560 <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: Michael Welsh Duggan <md5i <at> md5i.com> Cc: 9560 <at> debbugs.gnu.org Subject: Re: bug#9560: An exact recipe Date: Wed, 19 Oct 2011 10:16:18 +0000
Hi, Michael. On Wed, Oct 12, 2011 at 10:33:22PM -0400, Michael Welsh Duggan wrote: > >>>From emacs -Q: > Do NOT resize the frame. The recipe includes C-v, which depends on the > window (and hence frame) size. > Load the following file: [ .... ] > Type: > M-x edit-kbd-macro RET y C-x e C-x h C-w C-x i > When prompted, insert the following keyboard macro file: [ .... ] > Type: > C-c C-c > You should be back at rwsiteinfo-backup.c. Execute the macro using: > C-x e > Then type: > TAB OK, I've got about this far. I've been busy getting 5.32.2 into XEmacs. The first thing I'm going to do with this macro is replace the C-v's with an equivalent number of C-n's, because my frames on a tty are a fixed 65 lines (not including mode line and minibuffer) high. :-) Emacs's facilities for keyboard macros are not comfortable. > At this point, you should see the indentation move to just under the `o' > in "flowtype:list". This location is incorrect. If you then do the > following: > M-x set-variable RET c-echo-syntactic-information-p RET t RET TAB > you will see that c-mode believes the syntax at that point to be > topmost-intro-cont instead of the proper brace-list-entry. > When you have solved this bug, please let me know if the solution has a > reasonable chance of having solved the other problem that I have not > been able to recreate reliably, which is getting "topmost-intro indent > 0" instead of "statement indent 4" when in the middle of editing a > function. If these have little chance of being connected, I'll do my > best to try to create that scenario again (no promises). > -- > Michael Welsh Duggan > (md5i <at> md5i.com) -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org:bug#9560; Package emacs,cc-mode.
(Wed, 19 Oct 2011 13:47:02 GMT) Full text and rfc822 format available.Message #23 received at 9560 <at> debbugs.gnu.org (full text, mbox):
From: Michael Welsh Duggan <md5i <at> md5i.com> To: Alan Mackenzie <acm <at> muc.de> Cc: 9560 <at> debbugs.gnu.org Subject: Re: bug#9560: An exact recipe Date: Wed, 19 Oct 2011 09:45:45 -0400
Alan Mackenzie <acm <at> muc.de> writes: > Hi, Michael. > > On Wed, Oct 12, 2011 at 10:33:22PM -0400, Michael Welsh Duggan wrote: >> >>>From emacs -Q: > >> Do NOT resize the frame. The recipe includes C-v, which depends on the >> window (and hence frame) size. > >> Load the following file: > > [ .... ] > > >> Type: > >> M-x edit-kbd-macro RET y C-x e C-x h C-w C-x i > >> When prompted, insert the following keyboard macro file: > > [ .... ] > > >> Type: > >> C-c C-c > >> You should be back at rwsiteinfo-backup.c. Execute the macro using: > >> C-x e > >> Then type: > >> TAB > > OK, I've got about this far. I've been busy getting 5.32.2 into XEmacs. > The first thing I'm going to do with this macro is replace the C-v's with > an equivalent number of C-n's, because my frames on a tty are a fixed 65 > lines (not including mode line and minibuffer) high. :-) > > Emacs's facilities for keyboard macros are not comfortable. Okay, I've done some experimenting, and unfortunately, I have been unable to recreate this problem using this recipe using emacs -Q -nw. I've only encountered it using an X window. In this environment, I was able to recreate the problem consistently. I was able to replace the initial "3*C-v 7*C-n" in the macro with "100*C-n C-l" and this allowed it to work with larger frame sizes. Don't ask me why the C-l is necessary, as I do not know. >> At this point, you should see the indentation move to just under the `o' >> in "flowtype:list". This location is incorrect. If you then do the >> following: > >> M-x set-variable RET c-echo-syntactic-information-p RET t RET TAB > >> you will see that c-mode believes the syntax at that point to be >> topmost-intro-cont instead of the proper brace-list-entry. > >> When you have solved this bug, please let me know if the solution has a >> reasonable chance of having solved the other problem that I have not >> been able to recreate reliably, which is getting "topmost-intro indent >> 0" instead of "statement indent 4" when in the middle of editing a >> function. If these have little chance of being connected, I'll do my >> best to try to create that scenario again (no promises). > >> -- >> Michael Welsh Duggan >> (md5i <at> md5i.com) -- Michael Welsh Duggan (md5i <at> md5i.com)
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org:bug#9560; Package emacs,cc-mode.
(Wed, 19 Oct 2011 17:46:01 GMT) Full text and rfc822 format available.Message #26 received at 9560 <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: Michael Welsh Duggan <md5i <at> md5i.com> Cc: 9560 <at> debbugs.gnu.org Subject: Re: bug#9560: An exact recipe Date: Wed, 19 Oct 2011 17:39:35 +0000
Hi again, Michael. On Wed, Oct 19, 2011 at 09:45:45AM -0400, Michael Welsh Duggan wrote: > Alan Mackenzie <acm <at> muc.de> writes: > Okay, I've done some experimenting, and unfortunately, I have been > unable to recreate this problem using this recipe using emacs -Q -nw. > I've only encountered it using an X window. I found that too, on a tty - it's rather worrying. ;-( > In this environment, I was able to recreate the problem consistently. > I was able to replace the initial "3*C-v 7*C-n" in the macro with > "100*C-n C-l" and this allowed it to work with larger frame sizes. > Don't ask me why the C-l is necessary, as I do not know. I can now reproduce the problem consistently. As you surmised, the problem is in `c-state-cache', the cache of braces, parens, and brackets which is essential to CC Mode's operation. I'll see if I can get some instrumentation on `c-parse-state' so as to track down the exact point the cache is going wrong. I do hope such instrumentation won't make the error go away. > -- > Michael Welsh Duggan > (md5i <at> md5i.com) -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org:bug#9560; Package emacs,cc-mode.
(Thu, 20 Oct 2011 11:49:02 GMT) Full text and rfc822 format available.Message #29 received at 9560 <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: Michael Welsh Duggan <md5i <at> md5i.com> Cc: 9560 <at> debbugs.gnu.org Subject: Re: bug#9560: An exact recipe Date: Thu, 20 Oct 2011 11:42:29 +0000
Hi, Michael.
On Wed, Oct 19, 2011 at 09:45:45AM -0400, Michael Welsh Duggan wrote:
> Alan Mackenzie <acm <at> muc.de> writes:
> Okay, I've done some experimenting, and unfortunately, I have been
> unable to recreate this problem using this recipe using emacs -Q -nw.
> I've only encountered it using an X window.
That still perplexes me. I've got a fix, but the problem should have
appeared on a tty and a -nw too.
> In this environment, I was able to recreate the problem consistently.
> I was able to replace the initial "3*C-v 7*C-n" in the macro with
> "100*C-n C-l" and this allowed it to work with larger frame sizes.
> Don't ask me why the C-l is necessary, as I do not know.
> >> When you have solved this bug, please let me know if the solution has a
> >> reasonable chance of having solved the other problem that I have not
> >> been able to recreate reliably, which is getting "topmost-intro indent
> >> 0" instead of "statement indent 4" when in the middle of editing a
> >> function. If these have little chance of being connected, I'll do my
> >> best to try to create that scenario again (no promises).
I think there's a good chance of that bug being fixed by the following
patch (no promises ;-).
The bug was a bit of carelessness on my part. I'd done
(unless (and T1 T2 T3) ...)
, and in the body tested
(and T1 (not T3))
, which is rubbish, since that says nothing about the state of T2. T2
being the wrong way round was what caused the bug to show up.
Anyhow, here's the patch. Only the first chunk is for the bug; the rest
of it is the superior instrumentation. Let me know how this goes!
*** orig/cc-engine.el 2011-10-19 19:16:01.000000000 +0000
--- cc-engine.el 2011-10-20 11:22:15.000000000 +0000
***************
*** 2485,2491 ****
(<= from (cdr c-state-brace-pair-desert)))
;; Only search what we absolutely need to:
(if (and c-state-brace-pair-desert
! (> from (cdr c-state-brace-pair-desert)))
(narrow-to-region (cdr c-state-brace-pair-desert) (point-max)))
;; In the next pair of nested loops, the inner one moves back past a
--- 2485,2491 ----
(<= from (cdr c-state-brace-pair-desert)))
;; Only search what we absolutely need to:
(if (and c-state-brace-pair-desert
! (eq cache-pos (car c-state-brace-pair-desert)))
(narrow-to-region (cdr c-state-brace-pair-desert) (point-max)))
;; In the next pair of nested loops, the inner one moves back past a
***************
*** 3169,3174 ****
--- 3169,3204 ----
(unless (fboundp 'c-real-parse-state)
(fset 'c-real-parse-state (symbol-function 'c-parse-state)))
(cc-bytecomp-defun c-real-parse-state)
+
+ (defvar c-parse-state-state nil)
+ (defun c-record-parse-state-state ()
+ (setq c-parse-state-state
+ (mapcar
+ (lambda (arg)
+ (cons arg (symbol-value arg)))
+ '(c-state-cache
+ c-state-cache-good-pos
+ c-state-nonlit-pos-cache
+ c-state-nonlit-pos-cache-limit
+ c-state-brace-pair-desert
+ c-state-point-min
+ c-state-point-min-lit-type
+ c-state-point-min-lit-start
+ c-state-min-scan-pos
+ c-state-old-cpp-beg
+ c-state-old-cpp-end))))
+ (defun c-replay-parse-state-state ()
+ (let ((outstring "(setq "))
+ (mapc
+ (lambda (arg)
+ (setq outstring
+ (concat outstring
+ (format " %s %s%s"
+ (car arg) (if (atom (cdr arg)) "" "'") (cdr arg)))))
+ c-parse-state-state)
+ (setq outstring (concat outstring ")"))
+ (message outstring)))
+
(defun c-debug-parse-state ()
(let ((here (point)) (res1 (c-real-parse-state)) res2)
(let ((c-state-cache nil)
***************
*** 3187,3201 ****
;; The cache can actually go further back due to the ad-hoc way
;; the first paren is found, so try to whack off a bit of its
;; start before complaining.
! (save-excursion
! (goto-char (or (c-least-enclosing-brace res2) (point)))
! (c-beginning-of-defun-1)
! (while (not (or (bobp) (eq (char-after) ?{)))
! (c-beginning-of-defun-1))
! (unless (equal (c-whack-state-before (point) res1) res2)
! (message (concat "c-parse-state inconsistency at %s: "
! "using cache: %s, from scratch: %s")
! here res1 res2))))
res1))
(defun c-toggle-parse-state-debug (&optional arg)
--- 3217,3237 ----
;; The cache can actually go further back due to the ad-hoc way
;; the first paren is found, so try to whack off a bit of its
;; start before complaining.
! ;; (save-excursion
! ;; (goto-char (or (c-least-enclosing-brace res2) (point)))
! ;; (c-beginning-of-defun-1)
! ;; (while (not (or (bobp) (eq (char-after) ?{)))
! ;; (c-beginning-of-defun-1))
! ;; (unless (equal (c-whack-state-before (point) res1) res2)
! ;; (message (concat "c-parse-state inconsistency at %s: "
! ;; "using cache: %s, from scratch: %s")
! ;; here res1 res2)))
! (message (concat "c-parse-state inconsistency at %s: "
! "using cache: %s, from scratch: %s")
! here res1 res2)
! (message "Old state:")
! (c-replay-parse-state-state))
! (c-record-parse-state-state)
res1))
(defun c-toggle-parse-state-debug (&optional arg)
> --
> Michael Welsh Duggan
> (md5i <at> md5i.com)
--
Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs <at> gnu.org, bug-cc-mode <at> gnu.org:bug#9560; Package emacs,cc-mode.
(Fri, 21 Oct 2011 01:44:02 GMT) Full text and rfc822 format available.Message #32 received at 9560 <at> debbugs.gnu.org (full text, mbox):
From: Michael Welsh Duggan <md5i <at> md5i.com> To: Alan Mackenzie <acm <at> muc.de> Cc: 9560 <at> debbugs.gnu.org Subject: Re: bug#9560: An exact recipe Date: Thu, 20 Oct 2011 21:42:30 -0400
Alan Mackenzie <acm <at> muc.de> writes: > Hi, Michael. > > On Wed, Oct 19, 2011 at 09:45:45AM -0400, Michael Welsh Duggan wrote: >> Alan Mackenzie <acm <at> muc.de> writes: > >> Okay, I've done some experimenting, and unfortunately, I have been >> unable to recreate this problem using this recipe using emacs -Q -nw. >> I've only encountered it using an X window. > > That still perplexes me. I've got a fix, but the problem should have > appeared on a tty and a -nw too. Indeed. Could font-locking interfere at any point? >> In this environment, I was able to recreate the problem consistently. >> I was able to replace the initial "3*C-v 7*C-n" in the macro with >> "100*C-n C-l" and this allowed it to work with larger frame sizes. >> Don't ask me why the C-l is necessary, as I do not know. > >> >> When you have solved this bug, please let me know if the solution has a >> >> reasonable chance of having solved the other problem that I have not >> >> been able to recreate reliably, which is getting "topmost-intro indent >> >> 0" instead of "statement indent 4" when in the middle of editing a >> >> function. If these have little chance of being connected, I'll do my >> >> best to try to create that scenario again (no promises). > > I think there's a good chance of that bug being fixed by the following > patch (no promises ;-). We can always hope! > The bug was a bit of carelessness on my part. I'd done > (unless (and T1 T2 T3) ...) > , and in the body tested > (and T1 (not T3)) > , which is rubbish, since that says nothing about the state of T2. T2 > being the wrong way round was what caused the bug to show up. > > Anyhow, here's the patch. Only the first chunk is for the bug; the rest > of it is the superior instrumentation. Let me know how this goes! Well, it certainly fixes things in my initial tests. After checking in, I would consider this bug closed. I'll open up a new one if I notice something weird in the future. -- Michael Welsh Duggan (md5i <at> md5i.com)
Alan Mackenzie <acm <at> muc.de>:Michael Welsh Duggan <mwd <at> cert.org>:Message #37 received at 9560-done <at> debbugs.gnu.org (full text, mbox):
From: Alan Mackenzie <acm <at> muc.de> To: 9560-done <at> debbugs.gnu.org Subject: Bug #9560 fixed Date: Sat, 22 Oct 2011 11:26:47 +0000
Bug fixed. -- Alan Mackenzie (Nuremberg, Germany).
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Sat, 19 Nov 2011 12:24:03 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.