comment-enter-backward: Wrong type argument: number-or-marker-p, nil

[Stephen Berman]

In GNU Emacs 23.0.60.7 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of
2008-02-21 on escher I do this:

1. emacs -Q
2. C-x C-f test.c
3. Type this with no following newline: // test
4. C-SPC C-SPC C-a M-;
=> The line gets uncomments but Emacs throws an error
"comment-enter-backward: Wrong type argument: number-or-marker-p, nil"

Note that if the line typed at step 3 is this: /* test */ (also with no
following newline), then after step 4 there is no error.

AFAICT, the reason is as follows.  Since there is no comment-end,
re-search-forward in comment-enter-backward returns nil, so the second
clause of the cond gets evaluated.  But since in the first clause, point
moved to point-min, (car (syntax-after (- (point) 1))) evaluates to nil,
which is a wrong type argument for logand.  So point should be restored:

*** emacs/lisp/newcomment.el.~1.111.~   2008-01-16 10:20:45.000000000 +0100
--- emacs/lisp/newcomment.el    2008-02-21 11:34:01.000000000 +0100
***************
*** 492,501 ****
        ;; 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 probably because it was not set
       ;; right.  Since \\s> should catch the single-char case, let's
--- 492,502 ----
        ;; 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

If this is right, presumably it should also be fixed in EMACS_22_BASE.

Steve Berman