Space after inline comment char

Space after inline comment char

[Bill Wohler]

(elisp) Comment Tips does not say whether a space should follow a single
semicolon comment or not. The example and most of the code shows that a
space does follow the semicolon, but comment-dwim does not insert one.
It would be nice if it did.

In other words, M-; should do this:

  (defvar foo)                         ; _

rather than this:

  (defvar foo)                         ;_

where _ is the cursor after the comment is inserted.

I imagine this is too big an apple to crack now, but it would be nice to
know if this is an issue that folks would want to work on, and that it
was shelved for later consideration.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Space after inline comment char

[Stefan Monnier]

> (elisp) Comment Tips does not say whether a space should follow a single
> semicolon comment or not. The example and most of the code shows that a
> space does follow the semicolon, but comment-dwim does not insert one.
> It would be nice if it did.

That's easy: change comment-start from ";" to "; ".


        Stefan

Re: Space after inline comment char

[Ralf Angeli]

* Stefan Monnier (2006-04-15) writes:

>> (elisp) Comment Tips does not say whether a space should follow a single
>> semicolon comment or not. The example and most of the code shows that a
>> space does follow the semicolon, but comment-dwim does not insert one.
>> It would be nice if it did.
>
> That's easy: change comment-start from ";" to "; ".

Then commenting at the beginning of a line will not work correctly
anymore.  A better way would be to make `comment-indent' aware of
`comment-padding'.

-- 
Ralf

Re: Space after inline comment char

[Stefan Monnier]

>>> (elisp) Comment Tips does not say whether a space should follow a single
>>> semicolon comment or not. The example and most of the code shows that a
>>> space does follow the semicolon, but comment-dwim does not insert one.
>>> It would be nice if it did.
>> 
>> That's easy: change comment-start from ";" to "; ".

> Then commenting at the beginning of a line will not work correctly
> anymore.

What makes you think so?

AFAIK, the only side-effect it'll have is that there won't be a difference
between a comment-padding set to 1 or to 0.


        Stefan

Re: Space after inline comment char

[Ralf Angeli]

* Stefan Monnier (2006-04-16) writes:

>>> That's easy: change comment-start from ";" to "; ".
>
>> Then commenting at the beginning of a line will not work correctly
>> anymore.
>
> What makes you think so?
>
> AFAIK, the only side-effect it'll have is that there won't be a difference
> between a comment-padding set to 1 or to 0.

Try
emacs -Q -eval '(progn (setq comment-start "; ") (insert "foo\n") (comment-region (point-max) (point-min)))'

That will result in
; foo
whereas it should be
;; foo

-- 
Ralf

Re: Space after inline comment char

[Stefan Monnier]

>>>> That's easy: change comment-start from ";" to "; ".
>>> Then commenting at the beginning of a line will not work correctly
>>> anymore.
>> What makes you think so?
>> AFAIK, the only side-effect it'll have is that there won't be a difference
>> between a comment-padding set to 1 or to 0.

> Try
> emacs -Q -eval '(progn (setq comment-start "; ") (insert "foo\n") (comment-region (point-max) (point-min)))'

> That will result in
> ; foo
> whereas it should be
> ;; foo

Good point.  I believe the patch below has fixed it,


        Stefan


--- newcomment.el	03 fév 2006 10:56:11 -0500	1.91
+++ newcomment.el	16 avr 2006 23:48:30 -0400	
@@ -895,6 +895,11 @@
 		   (delete-char n)
 		   (setq ,bindent (- ,bindent n)))))))))))
 
+(defun comment-add (arg)
+  (if (and (null arg) (= (string-match "[ \t]*\\'" comment-start) 1))
+      comment-add
+    (1- (prefix-numeric-value arg))))
+
 (defun comment-region-internal (beg end cs ce
                                 &optional ccs cce block lines indent)
   "Comment region BEG .. END.
@@ -999,7 +1004,6 @@
 
 (defun comment-region-default (beg end &optional arg)
   (let* ((numarg (prefix-numeric-value arg))
-	 (add comment-add)
 	 (style (cdr (assoc comment-style comment-styles)))
 	 (lines (nth 2 style))
 	 (block (nth 1 style))
@@ -1032,8 +1036,7 @@
      ((consp arg) (uncomment-region beg end))
      ((< numarg 0) (uncomment-region beg end (- numarg)))
      (t
-      (setq numarg (if (and (null arg) (= (length comment-start) 1))
-		       add (1- numarg)))
+      (setq numarg (comment-add arg))
       (comment-region-internal
        beg end
        (let ((s (comment-padright comment-start numarg)))
@@ -1091,8 +1094,7 @@
 	;; FIXME: If there's no comment to kill on this line and ARG is
 	;; specified, calling comment-kill is not very clever.
 	(if arg (comment-kill (and (integerp arg) arg)) (comment-indent))
-      (let ((add (if arg (prefix-numeric-value arg)
-		   (if (= (length comment-start) 1) comment-add 0))))
+      (let ((add (comment-add arg)))
 	;; Some modes insist on keeping column 0 comment in column 0
 	;; so we need to move away from it before inserting the comment.
 	(indent-according-to-mode)

Re: Space after inline comment char

[Ralf Angeli]

* Stefan Monnier (2006-04-17) writes:

>> That will result in
>> ; foo
>> whereas it should be
>> ;; foo
>
> Good point.  I believe the patch below has fixed it,

It did.  I still think it would be nice if one could control spaces
after comment starterts with `comment-padding' _everywhere_,
i.e. after comment starters inserted by `comment-indent' as well.
That would feel more consistent.  But then, the doc string of
`comment-padding' only talks about `comment-region'.

-- 
Ralf

Re: Space after inline comment char

[Stefan Monnier]

>>> That will result in
>>> ; foo
>>> whereas it should be
>>> ;; foo
>> 
>> Good point.  I believe the patch below has fixed it,

> It did.  I still think it would be nice if one could control spaces
> after comment starterts with `comment-padding' _everywhere_,
> i.e. after comment starters inserted by `comment-indent' as well.
> That would feel more consistent.  But then, the doc string of
> `comment-padding' only talks about `comment-region'.

When I re-implemented the comment commands in newcomment.el, I just
preserved this part of the behavior (that comment-padding only applies to
comment-region but not to comment-indent).

I don't know what was the original motivation for it (if any), but without
introducting a separate comment-indent-padding, changing the behavior would
have meant that I'd have removed some functionality (the ability to
(indirectly) specify different amounts of padding), so I decided to keep it
as is.


        Stefan

Re: Space after inline comment char

[Bill Wohler]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>> That's easy: change comment-start from ";" to "; ".
>>>> Then commenting at the beginning of a line will not work correctly
>>>> anymore.
>>> What makes you think so?
>>> AFAIK, the only side-effect it'll have is that there won't be a difference
>>> between a comment-padding set to 1 or to 0.
>
>> Try
>> emacs -Q -eval '(progn (setq comment-start "; ") (insert "foo\n") (comment-region (point-max) (point-min)))'
>
>> That will result in
>> ; foo
>> whereas it should be
>> ;; foo
>
> Good point.  I believe the patch below has fixed it,

Yes, it has. Thanks!

Still, if most people insert a space after running M-;--as the sources
seem to indicate--it seems like including the space in the default for
comment-start is good usability. Plus it will help keep the look of
the comments in Emacs consistent, which is a good thing.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Space after inline comment char

[Richard Stallman]

There is no rule that comments must start with a space.
So we should not change Emacs to insist on that.