GNU bug report logs -
#38691
CC Mode 5.34 (C++//lhw); `Invalid search bound` when undo
Previous Next
Full log
View this message in rfc822 format
Hello, Wei.
Thanks for taking the trouble to report this bug, and thanks for
including a CC Mode configuration dump.
On Fri, Dec 20, 2019 at 10:13:32 +0000, Sun, Wei via CC-Mode-help wrote:
> Package: cc-mode
> $> cat test.cpp
> // 2019-12-20 17:57
> emacs -Q test.cpp
> M-x mark-page RET
> C-u M-x shell-command-on-region RET
> sort RET
> M-x undo RET
> Debugger entered--Lisp error: (error "Invalid search bound (wrong side of point)")
> search-forward-regexp("R\"\\([^ ()\\\n\15\11]\\{0,16\\}\\)(" -20 bound)
> c-after-change-unmark-raw-strings(1 1 21)
> #f(compiled-function (fn) #<bytecode 0x91e275>)(c-after-change-unmark-raw-strings)
> mapc(#f(compiled-function (fn) #<bytecode 0x91e275>) (c-depropertize-new-text c-after-change-escape-NL-in-string c-after-change-unmark-raw-strings c-parse-quotes-after-change c-after-change-mark-abnormal-strings c-extend-font-lock-region-for-macros c-neutralize-syntax-in-CPP c-restore-<>-properties c-change-expand-fl-region))
> c-after-change(1 1 21)
> primitive-undo(1 ((1 . 22) (#("// 2019-12-20 17:57\n\n" 0 1 (face font-lock-comment-delimiter-face c-is-sws t c-in-sws t fontified t) 1 3 (face font-lock-comment-delimiter-face c-in-sws t fontified t) 3 20 (face font-lock-comment-face c-in-sws t fontified t) 20 21 (fontified t c-is-sws t)) . 1) (#<marker at 1 in test.cpp> . -21) (#<marker in no buffer> . -21) (#<marker at 1 in test.cpp> . -21) (t 24060 40235 192206 220000) nil (#("-" 0 1 (fontified t)) . 1) nil (#("#include <test.hpp>" 0 1 (face font-lock-preprocessor-face c-is-sws t c-in-sws t fontified t) 1 8 (face font-lock-preprocessor-face c-in-sws t fontified t) 8 9 (c-in-sws t fontified t) 9 10 (category c-<-as-paren-syntax face font-lock-string-face c-in-sws t fontified t) 10 18 (face font-lock-string-face c-in-sws t fontified t) 18 19 (category c->-as-paren-syntax face font-lock-string-face c-in-sws t fontified t)) . 22) (t 24060 40193 724383 390000)))
> undo-more(1)
> undo(nil)
> funcall-interactively(undo nil)
> call-interactively(undo nil nil)
> command-execute(undo)
The cause of the bug is in the C routine call_process in the Emacs core.
This function calls the external process, and (in this case) writes its
output to an Emacs buffer. When it does this, it calls the Emacs hook
`before-change-functions' (as it should), but fails to call
`after-change-functions'. (These two hooks are documented in the Elisp
manual on page "Change Hooks".)
This failure to call `after-change-functions' confuses CC Mode. CC Mode
does have a workaround for this sort of thing, but it is not good enough
to correct for the bug in call_process in this case.
So.... I think the CC Mode workaround needs to be improved. I will be
looking at this. Also, I am currently negotiating with Eli Zaretskii
(the principle Emacs maintainer) to fix call_process. I am confident
this will happen.
I'm hoping that a fix will be in the Emacs-27 release branch (which was
created yesterday) within the next week or so.
> Package: cc-mode
> Emacs : GNU Emacs 27.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
> of 2019-12-20
> Package: CC Mode 5.34 (C++//lhw)
> Buffer Style: google
> c-emacs-features: (pps-extended-state col-0-paren posix-char-classes gen-string-delim gen-comment-delim syntax-properties 1-bit)
[ .... ]
--
Alan Mackenzie (Nuremberg, Germany).
This bug report was last modified 5 years and 142 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.