Subject: Re: bug#18970: 24.3; indent region fails in C++ mode after adding a #include

From: Alan Mackenzie <[email-masked]>
Date: Fri, 7 Nov 2014 23:24:44 +0000

Hello, Piotr.

On Fri, Nov 07, 2014 at 04:53:34PM -0500, Piotr Sipika wrote:
> Hi Alan,

> > This bug will be dependent on the exact contents of the file, or at least
> > the first few hundred or thousand bytes in it.  Is there any chance you
> > could post the file as it was just before you edited it in step 1., and
> > say exactly what keys you used for 1. - 4.?

> Hope this will help you: it seems that this problem has a higher rate of
> occurrence when I kill the line with the #include (C-k) and then paste
> it in (C-y). The buffer where the #include is inserted is the one where
> the indentation problem occurs (it may be the same buffer in which the
> line was killed).

Yes, indeed, that helps a great deal!

There was a problem with C-y'ing #include lines into a buffer back in
May 2013, which was fixed, and the fix got into Emacs 24.4 (which was
released a few days ago).

To confirm that your problem is the same one, would you please do the
following:
(i) Kill a line starting with "#include" with C-k, then yank it back
again with C-y.
(ii) Move point to the beginning of that line and type C-u C-x =
(`what-cursor-position' with a C-u prefix argument).
(iii) You should see something like this:

########################################################################
             position: 63 of 1339 (5%), column: 0
            character: # (displayed as #) (codepoint 35, #o43, #x23)
    preferred charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x23
               syntax: .        which means: punctuation
             category: .:Base, a:ASCII, l:Latin, r:Roman
             to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET
NAME"
          buffer code: #x23
            file code: #x23 (encoded by coding system undecided-unix)
              display: terminal code #x23

Character code properties: customize what to show
  name: NUMBER SIGN
  general-category: Po (Punctuation, Other)
  decomposition: (35) ('#')

There are text properties here:
  c-in-sws             t
  c-is-sws             t
  category             c-cpp-delimiter
  face                 font-lock-preprocessor-face
  fontified            t
  risky-local-variable t
  syntax-table         nil <===================================================

[back]
########################################################################

If you see the syntax-table text property set to nil, as in the above,
then we have found the bug.

Either upgrade your Emacs to version 24.4, or apply the following patch
to ..../emacs-24.3/lisp/progmodes/cc-mode.el:

=== modified file 'lisp/progmodes/cc-mode.el'
--- lisp/progmodes/cc-mode.el	2013-05-02 11:18:18 +0000
+++ lisp/progmodes/cc-mode.el	2013-05-27 13:30:21 +0000
@@ -1077,12 +1077,13 @@
 	    (setq beg end)))
 
 	;; C-y is capable of spuriously converting category properties
-	;; c-</>-as-paren-syntax into hard syntax-table properties.  Remove
-	;; these when it happens.
+	;; c-</>-as-paren-syntax and c-cpp-delimiter into hard syntax-table
+	;; properties.  Remove these when it happens.
 	(c-clear-char-property-with-value beg end 'syntax-table
 					  c-<-as-paren-syntax)
 	(c-clear-char-property-with-value beg end 'syntax-table
 					  c->-as-paren-syntax)
+	(c-clear-char-property-with-value beg end 'syntax-table nil)
 
 	(c-trim-found-types beg end old-len) ; maybe we don't need all of these.
 	(c-invalidate-sws-region-after beg end)

[If you have any problems applying the patch, get back to me privately.]

After applying the patch, byte compile cc-mode.el either with "M-x
byte-compile-file" inside emacs, or do it from the command line like
this:

$ emacs -Q -batch -f batch-byte-compile .../emacs-24.3/lisp/progmodes/cc-mode.el 

Then copy the compiled file cc-mode.elc to where emacs normally loads it
from.  You can find this with "M-x locate-library<CR>cc-mode<CR>" from
inside emacs.

Restart Emacs, and hopefully the bug will be gone.  Please let me know
whether or not this works.

Thanks!

> Piotr

-- 
Alan Mackenzie (Nuremberg, Germany).