cc-mode-help

CC Mode 5.31.4 (Java/l); Incorrent behaviour of uncomment-region in java-mode

[Guillaume S. <gui...@gm...>]

Hi,

I have a strange problem with uncomment-region eating my lines of
code. I can reproduce it deterministically by:

- starting emacs (with -Q)
- changing to java-mode (in the scratch buffer, for example)
- typing a two line c-style comment :

/* first line
second line */

- selecting all the buffer (or just the two lines)
- M-x uncomment region

I end up with the following text

first lin

(which is kinda scary, and has already caused me problems with lines
of code silentely disappearing, not causing a compile-time error but a
strange run-time behaviour instead. but I'm getting off-topic :-)

BTW, this is emacs 22.1.1 (CC Mode version 5.31.4), I get the same
behaviour with emacs 23.0.60.1 (CC Mode version 5.31.5), but it works
fine in emacs 21 (CC Mode version 5.28). I'm on ubuntu hardy.


Is this a known bug, or am I doing something wrong ?

Cheers,
-Guillaume



Emacs : GNU Emacs 22.1.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2008-05-03 on terranova, modified by Ubuntu
Package: CC Mode 5.31.4 (Java/l)
Buffer Style: java
c-emacs-features: (pps-extended-state col-0-paren posix-char-classes 
gen-string-delim gen-comment-delim syntax-properties 1-bit)

current state:
==============
(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 '((brace-list-open) (brace-entry-open)
(statement-cont) (substatement-open after)
(block-close . c-snug-do-while)
(extern-lang-open after) (namespace-open after)
(module-open after) (composition-open after)
(inexpr-class-open after)
(inexpr-class-close before))
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 nil
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)
(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)
(case-label . 0)
(substatement . +)
(statement-case-intro . +)
(statement . 0)
(brace-entry-open . 0)
(brace-list-entry . 0)
(brace-list-intro . +)
(brace-list-close . 0)
(brace-list-open . 0)
(block-close . 0)
(block-open . 0)
(inher-intro . +)
(member-init-cont . c-lineup-multi-inher)
(member-init-intro . +)
(topmost-intro . 0)
(knr-argdecl . 0)
(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)
(func-decl-cont . c-lineup-java-throws)
(inher-cont . c-lineup-java-inher)
(access-label . 0)
(arglist-close . c-lineup-arglist)
(arglist-intro . c-lineup-arglist-intro-after-paren)
(statement-cont . +)
(statement-case-open . +)
(label . +)
(substatement-label . +)
(substatement-open . +)
(knr-argdecl-intro . 5)
(statement-block-intro . +)
(topmost-intro-cont . +)
(inline-open . 0)
)
c-buffer-is-cc-mode 'java-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 nil
auto-fill-function nil
comment-multi-line t
comment-start-skip "\\(//+\\|/\\*+\\)\\s *"
fill-prefix nil
fill-column 70
paragraph-start "[ ]*\\(//+\\|\\**\\)[ ]*\\(@[a-zA-Z]+\\>\\|$\\)\\|^\f"
adaptive-fill-mode t
adaptive-fill-regexp "[ ]*\\(//+\\|\\**\\)[ ]*\\([ 
]*\\([-!|#%;>*·•‣⁃◦]+[ ]*\\)*\\)"
)

Re: CC Mode 5.31.4 (Java/l); Incorrent behaviour of uncomment-region in java-mode

[Alan M. <ac...@mu...>]

Hi, Guillaume!

On Tue, Oct 14, 2008 at 07:26:41PM +1000, Guillaume Salagnac wrote:
> Hi,

> I have a strange problem with uncomment-region eating my lines of
> code. I can reproduce it deterministically by:

> - starting emacs (with -Q)
> - changing to java-mode (in the scratch buffer, for example)
> - typing a two line c-style comment :

> /* first line
> second line */

> - selecting all the buffer (or just the two lines)
> - M-x uncomment region

> I end up with the following text

> first lin

> (which is kinda scary, and has already caused me problems with lines
> of code silentely disappearing, not causing a compile-time error but a
> strange run-time behaviour instead. but I'm getting off-topic :-)
 
Outch!  That's not nice!

> BTW, this is emacs 22.1.1 (CC Mode version 5.31.4), I get the same
> behaviour with emacs 23.0.60.1 (CC Mode version 5.31.5), but it works
> fine in emacs 21 (CC Mode version 5.28). I'm on ubuntu hardy.
 
> 
> Is this a known bug, or am I doing something wrong ?
 
Neither!  It is a new bug.  Thank you indeed for taking the trouble to
write such a concise bug report, complete with C-c C-b dump.

I can reproduce the bug exactly as you describe.

I think there is a problem in Emacs itself rather than CC Mode.  Give me
a few days, and hopefully I can fix it.
 
Thanks for sending this bug report.
 
> Cheers,
> -Guillaume

[ CC Mode configuration dump appreciated and snipped. ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: CC Mode 5.31.4 (Java/l); Incorrent behaviour of uncomment-region in java-mode

[Alan M. <ac...@mu...>]

Hi, Guillaume!

On Tue, Oct 14, 2008 at 07:26:41PM +1000, Guillaume Salagnac wrote:
> Hi,

> I have a strange problem with uncomment-region eating my lines of
> code. I can reproduce it deterministically by:

> - starting emacs (with -Q)
> - changing to java-mode (in the scratch buffer, for example)
> - typing a two line c-style comment :

> /* first line
> second line */

> - selecting all the buffer (or just the two lines)
> - M-x uncomment region

> I end up with the following text

> first lin

> (which is kinda scary, and has already caused me problems with lines
> of code silentely disappearing, not causing a compile-time error but a
> strange run-time behaviour instead. but I'm getting off-topic :-)

> BTW, this is emacs 22.1.1 (CC Mode version 5.31.4), I get the same
> behaviour with emacs 23.0.60.1 (CC Mode version 5.31.5), but it works
> fine in emacs 21 (CC Mode version 5.28). I'm on ubuntu hardy.


> Is this a known bug, or am I doing something wrong ?

Yes, it was indeed a known bug: A `save-excursion' had been omitted from
the function `comment-enter-backward' in ..../lisp/newcomment.el.

I would recommend you to upgrade your emacs to 22.3.  You can download
the tarball from <http://ftp.gnu.org/pub/gnu/emacs/emacs-22.3.tar.gz>.
It is easy indeed to build, especially on a system as common as Ubuntu.
Or you might be able to download it as a Ubuntu style package from
somewhere, which would be even easier.

Alternatively, if you really don't want to upgrade your emacs, apply this
patch to ...../lisp/newcomment.el, and byte-compile it, replacing the
existing newcomment.elc.  If you need any help applying the patch or
byte-compiling, feel free to send me a personal Email.

*** /usr/local/share/emacs/22.1/lisp/newcomment.el	2007-05-14 14:56:29.000000000 +0000
--- /home/acm/emacs/emacs/lisp/newcomment.el	2008-05-29 18:19:55.000000000 +0000
***************
*** 486,506 ****
        ;; comment-end = ""
        (progn (backward-char) (skip-syntax-backward " "))
      (cond
!      ((save-restriction
!         (narrow-to-region (line-beginning-position) (point))
!         (goto-char (point-min))
!         (re-search-forward (concat comment-end-skip "\\'") nil t))
        (goto-char (match-beginning 0)))
!      ;; comment-end-skip not found.  Maybe we're at EOB which implicitly
!      ;; closes the comment.
!      ((eobp) (skip-syntax-backward " "))
!      (t
!       ;; else comment-end-skip was not found probably because it was not
!       ;; set right.  Since \\s> should catch the single-char case, we'll
!       ;; blindly assume we're at the end of a two-char comment-end.
        (backward-char 2)
        (skip-chars-backward (string (char-after)))
!       (skip-syntax-backward " ")))))
  
  ;;;;
  ;;;; Commands
--- 490,519 ----
        ;; comment-end = ""
        (progn (backward-char) (skip-syntax-backward " "))
      (cond
!      ((save-excursion
!         (save-restriction
!           (narrow-to-region (line-beginning-position) (point))
!           (goto-char (point-min))
!           (re-search-forward (concat comment-end-skip "\\'") nil t)))
        (goto-char (match-beginning 0)))
!      ;; comment-end-skip not found probably because it was not set
!      ;; right.  Since \\s> should catch the single-char case, let's
!      ;; check that we're looking at a two-char comment ender.
!      ((not (or (<= (- (point-max) (line-beginning-position)) 1)
!                (zerop (logand (car (syntax-after (- (point) 1)))
!                               ;; Here we take advantage of the fact that
!                               ;; the syntax class " " is encoded to 0,
!                               ;; so "  4" gives us just the 4 bit.
!                               (car (string-to-syntax "  4"))))
!                (zerop (logand (car (syntax-after (- (point) 2)))
!                               (car (string-to-syntax "  3"))))))
        (backward-char 2)
        (skip-chars-backward (string (char-after)))
!       (skip-syntax-backward " "))
!      ;; No clue what's going on: maybe we're really not right after the
!      ;; end of a comment.  Maybe we're at the "end" because of EOB rather
!      ;; than because of a marker.
!      (t (skip-syntax-backward " ")))))
  
  ;;;;
  ;;;; Commands




> Cheers,
> -Guillaume

-- 
Alan Mackenzie (Nuremberg, Germany).