Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

problems with c-fill-paragraph, c++ comments in c modules

46 views
Skip to first unread message

Ragweed

unread,
Aug 23, 2010, 6:06:38 PM8/23/10
to
I've recently built Emacs 23.2.1 on a linux box and it doesn't behave
the same as the Emacs 21.4.1 on the same host with respect to c++
comments in a c file. I can't figure out how to get Emacs 23.2.1 to
run c-fill-paragraph properly for c++-style comments when they're in a
c file.

Consider the following long c++ style comment in a file named test.c:
>// The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog.

If I run c-fill-paragraph with the cursor on that line, Emacs 21.4.1
converts it to what I want:
>// The quick brown fox jumps over the lazy dog. The quick brown fox jumps over
>// the lazy dog. The quick brown fox jumps over the lazy dog.

If I run c-fill-paragraph in 23.2.1, I get:
// The quick brown fox jumps over the lazy dog. The quick brown fox
jumps over
the lazy dog. The quick brown fox jumps over the lazy dog.

That is, it wraps the comment to the next line but doesn't prefix the
next line with the comment prefix.

If I rename the file to test.cpp, then emacs 23.2.1 DOES prefix the
line.

I renamed my .emacs file so that both versions of Emacs use their
default settings and ignore my normal customizations.

Alan Mackenzie

unread,
Aug 27, 2010, 4:13:19 PM8/27/10
to
Hi, Ragweed,

Thanks for taking the trouble to report this bug. It was actually
reported a couple of months ago and fixed in the repository.

Would you please try applying the following patch (in directory
..../lisp/progmodes), compile the changed file (or just rebuild Emacs
again), and report whether or not the patch does fix the problem.

Thanks!

Here is the patch:

*** orig/cc-cmds.el 2010-07-05 20:17:46.000000000 +0000
--- cc-cmds.el 2010-07-11 18:46:13.066679040 +0000
***************
*** 3975,3980 ****
--- 3975,3988 ----
(goto-char ender-start)
(current-column)))
(point-rel (- ender-start here))
+ (sentence-ends-comment
+ (save-excursion
+ (goto-char ender-start)
+ (and (search-backward-regexp
+ (c-sentence-end) (c-point 'bol) t)
+ (goto-char (match-end 0))
+ (looking-at "[ \t]*")
+ (= (match-end 0) ender-start))))
spaces)

(save-excursion
***************
*** 4017,4023 ****
(setq spaces
(max
(min spaces
! (if sentence-end-double-space 2 1))
1)))
;; Insert the filler first to keep marks right.
(insert-char ?x spaces t)
--- 4025,4033 ----
(setq spaces
(max
(min spaces
! (if (and sentence-ends-comment
! sentence-end-double-space)
! 2 1))
1)))
;; Insert the filler first to keep marks right.
(insert-char ?x spaces t)
***************
*** 4229,4236 ****
(let ((fill-paragraph-function
;; Avoid infinite recursion.
(if (not (eq fill-paragraph-function 'c-fill-paragraph))
! fill-paragraph-function)))
! (c-mask-paragraph t nil 'fill-paragraph arg))
;; Always return t. This has the effect that if filling isn't done
;; above, it isn't done at all, and it's therefore effectively
;; disabled in normal code.
--- 4239,4249 ----
(let ((fill-paragraph-function
;; Avoid infinite recursion.
(if (not (eq fill-paragraph-function 'c-fill-paragraph))
! fill-paragraph-function))
! (start-point (point-marker)))
! (c-mask-paragraph
! t nil (lambda () (fill-region-as-paragraph (point-min) (point-max) arg)))
! (goto-char start-point))
;; Always return t. This has the effect that if filling isn't done
;; above, it isn't done at all, and it's therefore effectively
;; disabled in normal code.

--
Alan Mackenzie (Nuremberg, Germany).

0 new messages