GNU bug report logs - #36802
CC Mode 5.34 (C/*l); Spurious indentation in line after open #include

Previous Next

Package: cc-mode;

Reported by: Richard Copley <rcopley <at> gmail.com>

Date: Wed, 24 Jul 2019 20:05:01 UTC

Severity: normal

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 36802 <at> debbugs.gnu.org
Subject: bug#36802: CC Mode 5.34 (C/*l); Spurious indentation in line after open #include
Date: Thu, 25 Jul 2019 09:23:23 +0000
Hello agin, Richard.

On Wed, Jul 24, 2019 at 21:04:03 +0100, Richard Copley wrote:
> Package: cc-mode

> (From "emacs -Q".) In an empty C++ buffer, type [#include SPC <ab> C-p
> BACKSPACE C-e RET], or (for a more realistic example), correct
> "#include <asio/asio.hpp>" to "#include <asio.hpp>" like this:

>  ...asio.hpp             ;; self-insert-command
>  >                       ;; c-electric-lt-gt
>  M-b                     ;; backward-word
>  M-b                     ;; backward-word
>  <C-backspace>           ;; backward-kill-word
>  M->                     ;; end-of-buffer
>  <return>                ;; newline

> The new line is indented one level (expected zero levels). This
> corrects itself after doing M-x normal mode.

Thanks for the bug report.

> Reproduced below is the story so far, which comes after a discussion
> of unrelated matters at bug#36397.

> On Tue, 23 Jul 2019 at 14:10, Alan Mackenzie <acm <at> muc.de> wrote:

>     On Mon, Jul 22, 2019 at 20:47:22 +0100, Richard Copley wrote:

>     [ .... ]

>     This was an error in the macro cache handling.  After the deletion
>     of the >, the cache failed to adjust its upper bound downwards by
>     one.  Thus the cache was still representing that the beginning of
>     the new line was inside the macro bounds.

>     The following patch should fix this.  Would you please do the
>     usual with it.

>     Just as a matter of interest, how on earth did you manage to
>     stumble across the key sequence (above) which triggers this bug?

> (The patch, by Alan, is elided by Richard in this email opening the bug
> report.)

Here is the patch, again.  I'm very confident that this fixes the bug
properly.  Unless I hear otherwise within a day or two, I'll be
committing this patch and closing the bug.


diff -r 2e20f0567ddf cc-engine.el
--- a/cc-engine.el	Tue Jul 23 09:45:20 2019 +0000
+++ b/cc-engine.el	Tue Jul 23 13:00:17 2019 +0000
@@ -278,6 +278,11 @@
     (setcdr c-macro-cache nil)
     (setq c-macro-cache-start-pos beg
 	  c-macro-cache-syntactic nil
+	  c-macro-cache-no-comment nil))
+   ((and c-macro-cache-start-pos
+	 (< beg (c-macro-cache-start-pos)))
+    (setq c-macro-cache-start-pos beg
+	  c-macro-cache-syntactic nil
 	  c-macro-cache-no-comment nil))))
 
 (defun c-macro-is-genuine-p ()


> Emacs  : GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32)
>  of 2019-07-23
> Package: CC Mode 5.34 (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)

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).




This bug report was last modified 6 years and 22 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.