bug#50840: 28.0.50; Support GNU style of multiline comments in C source code

bug#50840: 28.0.50; Support GNU style of multiline comments in C source code

[Eli Zaretskii]

It sounds like none of the comment styles in 'comment-styles' can
produce the style of C code comments that we use in Emacs, i.e.

    /* This is the first line of a multi-line comment.
       This is the final line of a multi-line comment.  */

And I don't see anything in the CC Mode manual to augment that,
either.

Is this true?  If so, a feature request: add a style to support that.
If such a style already exists, please clarify the documentation so that
users could understand which style does that.

And one more nit: Can the 'comment-end' inserted after the end of a
comment please keep _two_ spaces after the period that ends the last
line of a comment?  Or at least heed the setting of
'sentence-end-double-space'?

Thanks.

In GNU Emacs 28.0.50 (build 1891, i686-pc-mingw32)
 of 2021-09-27 built on HOME-C4E4A596F7
Repository revision: d45b3e03c96813e10f8de3c375a5310c01623dab
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int --with-modules
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM
ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty
make-network-process emacs)

Memory information:
((conses 16 56764 6239)
 (symbols 48 7798 1)
 (strings 16 21663 2718)
 (string-bytes 1 633064)
 (vectors 16 13627)
 (vector-slots 8 179704 10721)
 (floats 8 23 53)
 (intervals 40 265 116)
 (buffers 888 10))

bug#50840: 28.0.50; Support GNU style of multiline comments in C source code

[Alan Mackenzie]

Hello, Eli.

On Mon, Sep 27, 2021 at 10:56:17 +0300, Eli Zaretskii wrote:

> It sounds like none of the comment styles in 'comment-styles' can
> produce the style of C code comments that we use in Emacs, i.e.

>     /* This is the first line of a multi-line comment.
>        This is the final line of a multi-line comment.  */

> And I don't see anything in the CC Mode manual to augment that,
> either.

On pressing M-; in gnu style in C Mode, you get

    /*  */

, with two spaces between the asterisks.

With an existing comment, and point in the middle of the comment:

   /* foobar barfoo */
            ^
	  point

, on pressing CR, you get

  /* foobar
     barfoo */

If auto-fill-mode is enabled, and one types past fill-column, the new
comment line produced by auto-fill is indented to the desired column.

Thus far, this produces Emacs style C comments.

#########################################################################

However, if point is at the end of the first line of a comment and CR is
pressed:

   /* foobar foobar foobar foobar */
                                 ^
			       point

,  you get

   /* foobar foobar foobar foobar
   */
   ^
 point

..  This seems reasonable for a commenting style that ends with */ alone
on the last line.  But it is inconvenient for the second/subsequent line
of an Emacs style comment.  Is this what you mean by "none of the
comment styles ... produce the ... comments that we use in Emacs"?

If so, we could enhance auto-fill-mode to refill when a space is typed
immediately before a comment closer.  But that somehow doesn't feel
quite right.

Ideally, we want some sort of electric indentation immediately on typing
any character before a comment closer alone on a line:

  /* foobar
  */
  ^
point

, on typing an f should go to

  /* foobar
     f*/

, or possibly even to

  /* foobar
     f */

..  I would be in favour of implementing this as a new feature, but
strictly restricted to the exact scenario above, namely:
(i) point is directly at the comment closer.
(ii) point is in the same column as the comment opener above.
This should minimise irritation to people typing in spaces to draw
pictures in comments, e.g. with |, \, -, /, and suchlike.

This should probably be coded inside lisp/newcomment.el, somehow.  Maybe
we could introduce a new component into the elements of comment-styles
meaning "re-indent bare comment-ender line on typing a self-insert
character".


> Is this true?  If so, a feature request: add a style to support that.
> If such a style already exists, please clarify the documentation so that
> users could understand which style does that.

> And one more nit: Can the 'comment-end' inserted after the end of a
> comment please keep _two_ spaces after the period that ends the last
> line of a comment?  Or at least heed the setting of
> 'sentence-end-double-space'?

Are we talking about C-c C-c (aka M-x comment-region) here?  This
command currently inserts comment-end (in C Mode, " */") at the end of
each line being commented, which will leave a single space between what
was the last "." on the line and the "*/".

We could surely check for an end of sentence character at EOL here, and
if we've got one, check that at least two spaces are left.  This again
would be something for lisp/newcomment.el.

> Thanks.

> In GNU Emacs 28.0.50 (build 1891, i686-pc-mingw32)
>  of 2021-09-27 built on HOME-C4E4A596F7
> Repository revision: d45b3e03c96813e10f8de3c375a5310c01623dab
> Repository branch: master
> Windowing system distributor 'Microsoft Corp.', version 5.1.2600
> System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

> Configured using:
>  'configure -C --prefix=/d/usr --with-wide-int --with-modules
>  --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

> Configured features:
> ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
> W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM
> ZLIB

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#50840: 28.0.50; Support GNU style of multiline comments in C source code

[Eli Zaretskii]

> Date: Mon, 27 Sep 2021 18:35:50 +0000
> Cc: 50840@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
>   acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > Is this true?  If so, a feature request: add a style to support that.
> > If such a style already exists, please clarify the documentation so that
> > users could understand which style does that.
> 
> > And one more nit: Can the 'comment-end' inserted after the end of a
> > comment please keep _two_ spaces after the period that ends the last
> > line of a comment?  Or at least heed the setting of
> > 'sentence-end-double-space'?
> 
> Are we talking about C-c C-c (aka M-x comment-region) here?

Yes, my use case, and the context in which I filed the bug report, was
"C-c C-c".  Not only for the 2 spaces issue, but also for the comment
style.

> This command currently inserts comment-end (in C Mode, " */") at the
> end of each line being commented, which will leave a single space
> between what was the last "." on the line and the "*/".
> 
> We could surely check for an end of sentence character at EOL here, and
> if we've got one, check that at least two spaces are left.  This again
> would be something for lisp/newcomment.el.

Probably.  That''s why Stefan was CC'ed as well.

bug#50840: 28.0.50; Support GNU style of multiline comments in C source code

[Alan Mackenzie]

Hello, Eli.

On Mon, Sep 27, 2021 at 21:51:45 +0300, Eli Zaretskii wrote:
> > Date: Mon, 27 Sep 2021 18:35:50 +0000
> > Cc: 50840@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
> >   acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > Is this true?  If so, a feature request: add a style to support that.
> > > If such a style already exists, please clarify the documentation so that
> > > users could understand which style does that.

> > > And one more nit: Can the 'comment-end' inserted after the end of a
> > > comment please keep _two_ spaces after the period that ends the last
> > > line of a comment?  Or at least heed the setting of
> > > 'sentence-end-double-space'?

> > Are we talking about C-c C-c (aka M-x comment-region) here?

> Yes, my use case, and the context in which I filed the bug report, was
> "C-c C-c".  Not only for the 2 spaces issue, but also for the comment
> style.

> > This command currently inserts comment-end (in C Mode, " */") at the
> > end of each line being commented, which will leave a single space
> > between what was the last "." on the line and the "*/".

> > We could surely check for an end of sentence character at EOL here, and
> > if we've got one, check that at least two spaces are left.  This again
> > would be something for lisp/newcomment.el.

> Probably.  That''s why Stefan was CC'ed as well.

OK.  Here's a provisional patch to lisp/newcomment.el that tries to fix
the two spaces at the end of a sentence issue.  I haven't got anywhere
with the main bug, yet.



diff --git a/lisp/newcomment.el b/lisp/newcomment.el
index b458f0356d..8865613383 100644
--- a/lisp/newcomment.el
+++ b/lisp/newcomment.el
@@ -1162,7 +1162,8 @@ comment-region-internal
       (unless (or ce-sanitized (eolp)) (insert "\n") (indent-according-to-mode))
       (comment-with-narrowing beg end
 	(let ((min-indent (point-max))
-	      (max-indent 0))
+	      (max-indent 0)
+              ceeee extra-spaces eos-col)
 	  (goto-char (point-min))
 	  ;; Quote any nested comment marker
 	  (comment-quote-nested comment-start comment-end nil)
@@ -1174,6 +1175,25 @@ comment-region-internal
 		(unless (looking-at "[ \t]*$")
 		  (setq min-indent (min min-indent (current-indentation))))
 		(end-of-line)
+                ;; Do we need extra spaces at an end of sentence?
+                (setq ceeee (if (eobp) ce cce))
+                (setq extra-spaces
+                      (and ceeee
+                           (save-excursion
+                             (skip-chars-backward "  \t")
+                             (setq eos-col (current-column))
+                             (or (bolp) (backward-char))
+                             (looking-at (sentence-end)))
+                           (max (- (if sentence-end-double-space 2 1)
+                                   (- (current-column) eos-col)
+                                   (if ceeee
+                                       (progn
+                                         (string-match "^[  \t]*" ceeee)
+                                         (match-end 0)) ; # spaces in ce/cce.
+                                     0))
+                                0)))
+                (when (and extra-spaces (> extra-spaces 0))
+                  (move-to-column (+ (current-column) extra-spaces) t))
 		(setq max-indent (max max-indent (current-column)))
 		(not (or (eobp) (progn (forward-line) nil)))))
 

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#50840: 28.0.50; Support GNU style of multiline comments in C source code

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> OK.  Here's a provisional patch to lisp/newcomment.el that tries to fix
> the two spaces at the end of a sentence issue.  I haven't got anywhere
> with the main bug, yet.

Thanks, Alan.  This looks good.
Only one request: could you put the bulk of the new code into a separate function?
I'll see about the "main bug" ASAP,


        Stefan

bug#50840: 28.0.50; Support GNU style of multiline comments in C source code

[Alan Mackenzie]

Hello, Stefan.

On Wed, Sep 29, 2021 at 08:08:43 -0400, Stefan Monnier wrote:
> > OK.  Here's a provisional patch to lisp/newcomment.el that tries to fix
> > the two spaces at the end of a sentence issue.  I haven't got anywhere
> > with the main bug, yet.

> Thanks, Alan.  This looks good.
> Only one request: could you put the bulk of the new code into a separate function?
> I'll see about the "main bug" ASAP,

How about the patch below?  It's not perfect - the move-to-column might
insert a tab at EOL, which will then be the Wrong Thing after the
function inserts the comment opener at the left margin.  Or something
like that.  Maybe we should bind indent-tabs-mode to nil around  the
move-to-column.

I'll leave the "main bug" to you, then.



diff --git a/lisp/newcomment.el b/lisp/newcomment.el
index b458f0356d..5e8691890d 100644
--- a/lisp/newcomment.el
+++ b/lisp/newcomment.el
@@ -1124,6 +1124,27 @@ comment-add
       (* comment-add 1)
     (1- (prefix-numeric-value arg))))
 
+(defun comment--sentence-spaces (c-end)
+  "Add spaces at EOL in a comment if needed for an end of sentence.
+C-END, a string, is the comment ender for the current line.  When
+called, point must be at the end of the line, and will be left
+at the possibly changed EOL at the end of this function."
+  (let (extra-spaces eos-col)
+    (setq extra-spaces
+          (and (save-excursion
+                 (skip-chars-backward "  \t")
+                 (setq eos-col (current-column))
+                 (or (bolp) (backward-char))
+                 (looking-at (sentence-end)))
+               (max (- (if sentence-end-double-space 2 1)
+                       (- (current-column) eos-col)
+                       (progn
+                         (string-match "^[  \t]*" c-end)
+                         (match-end 0))) ; # spaces in ce/cce.
+                    0)))
+  (when (and extra-spaces (> extra-spaces 0))
+    (move-to-column (+ (current-column) extra-spaces) t))))
+
 (defun comment-region-internal (beg end cs ce
                                 &optional ccs cce block lines indent)
   "Comment region BEG .. END.
@@ -1174,6 +1195,8 @@ comment-region-internal
 		(unless (looking-at "[ \t]*$")
 		  (setq min-indent (min min-indent (current-indentation))))
 		(end-of-line)
+                (let ((c-end (if (eobp) ce cce)))
+                  (if c-end (comment--sentence-spaces c-end)))
 		(setq max-indent (max max-indent (current-column)))
 		(not (or (eobp) (progn (forward-line) nil)))))



>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#50840: 28.0.50; Support GNU style of multiline comments in C source code

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> It sounds like none of the comment styles in 'comment-styles' can
> produce the style of C code comments that we use in Emacs, i.e.
>
>     /* This is the first line of a multi-line comment.
>        This is the final line of a multi-line comment.  */
>
> And I don't see anything in the CC Mode manual to augment that,
> either.

I'm not sure exactly what that would mean in practice.
`comment-style` is used to comment out code rather than to write the
text of a comment.  I think what you're asking for is what you get by
setting `comment-multi-line` and then writing your text (e.g. starting
with M-; and then typing the text in there, maybe with auto-fill set).

If you want comment-region to produce something like the above, then
maybe a patch like the following would make sense?
The idea is to add a new value nil to `comment-style` which would
instruct `comment-region` to refrain from adding `comment-continue` on
eachline of a multiline comment.


        Stefan


diff --git a/lisp/newcomment.el b/lisp/newcomment.el
index 52e7f09b693..619353d72fd 100644
--- a/lisp/newcomment.el
+++ b/lisp/newcomment.el
@@ -279,13 +277,13 @@ comment-style
 See `comment-styles' for a list of available styles."
   :type (if (boundp 'comment-styles)
 	    `(choice
+              (cons :tag "nil: Minimal" nil)
               ,@(mapcar (lambda (s)
                           `(const :tag ,(format "%s: %s" (car s) (nth 5 s))
                                   ,(car s)))
                         comment-styles))
 	  'symbol)
-  :version "23.1"
-  :group 'comment)
+  :version "23.1")
 
 ;;;###autoload
 (defcustom comment-padding (purecopy " ")
@@ -345,9 +339,7 @@ comment-string-strip
 			"\\'") str)
   (match-string 1 str))
 
-(defun comment-string-reverse (s)
-  "Return the mirror image of string S, without any trailing space."
-  (comment-string-strip (concat (nreverse (string-to-list s))) nil t))
+(define-obsolete-function-alias 'comment-string-reverse #'reverse "29.1")
 
 ;;;###autoload
 (defun comment-normalize-vars (&optional noerror)
@@ -933,7 +925,10 @@ uncomment-region-default-1
   (let* ((numarg (prefix-numeric-value arg))
 	 (ccs comment-continue)
 	 (srei (or (comment-padright ccs 're)
-		   (and (stringp comment-continue) comment-continue)))
+		   ;; `comment-padright' returns nil for whitespace-only
+                   ;; strings.
+		   (and (stringp comment-continue)
+		        comment-continue)))
 	 (csre (comment-padright comment-start 're))
 	 (sre (and srei (concat "^\\s-*?\\(" srei "\\)")))
 	 spt)
@@ -1005,8 +1000,8 @@ uncomment-region-default-1
 
 	  ;; Eliminate continuation markers as well.
 	  (when sre
-	    (let* ((cce (comment-string-reverse (or comment-continue
-						    comment-start)))
+	    (let* ((cce (reverse (or comment-continue
+				     comment-start)))
 		   (erei (and box (comment-padleft cce 're)))
 		   (ere (and erei (concat "\\(" erei "\\)\\s-*$"))))
 	      (goto-char (point-min))
@@ -1149,7 +1144,7 @@ comment-region-internal
     ;; Should we mark empty lines as well ?
     (if (or ccs block lines) (setq no-empty nil))
     ;; Make sure we have end-markers for BLOCK mode.
-    (when block (unless ce (setq ce (comment-string-reverse cs))))
+    (when block (unless ce (setq ce (reverse cs))))
     ;; If BLOCK is not requested, we don't need CCE.
     (unless block (setq cce nil))
     ;; Continuation defaults to the same as CS and CE.
@@ -1244,7 +1239,7 @@ comment-region-default-1
 	 (style (cdr (assoc comment-style comment-styles)))
 	 (lines (nth 2 style))
 	 (block (nth 1 style))
-	 (multi (nth 0 style)))
+	 (multi (if style (nth 0 style) t)))
 
     (if noadjust
         (when (bolp)
@@ -1297,10 +1292,9 @@ comment-region-default-1
 	;; In Lisp and similar modes with one-character comment starters,
 	;; double it by default if `comment-add' says so.
 	;; If it isn't indented, triple it.
-	(if (and (null arg) (not multi-char))
-	    (setq numarg (* comment-add (if triple 2 1)))
-	  (setq numarg (1- (prefix-numeric-value arg))))
-
+	(setq numarg (if (and (null arg) (not multi-char))
+	                 (* comment-add (if triple 2 1))
+	               (1- (prefix-numeric-value arg))))
 	(comment-region-internal
 	 beg end
 	 (let ((s (comment-padright comment-start numarg)))
@@ -1309,13 +1303,17 @@ comment-region-default-1
 	 (let ((s (comment-padleft comment-end numarg)))
 	   (and s (if (string-match comment-end-skip s) s
 		    (comment-padright comment-end))))
-	 (if multi
-             (or (comment-padright comment-continue numarg)
-                 ;; `comment-padright' returns nil when
-                 ;; `comment-continue' contains only whitespace
-                 (and (stringp comment-continue) comment-continue)))
-	 (if multi
-	     (comment-padleft (comment-string-reverse comment-continue) numarg))
+	 (cond
+          ((not style) (make-string (string-width cs) ""))
+          (multi
+           (or (comment-padright comment-continue numarg)
+               ;; `comment-padright' returns nil when
+               ;; `comment-continue' contains only whitespace
+               (and (stringp comment-continue) comment-continue))))
+	 (cond
+          ((not style) "")
+	  (multi
+	   (comment-padleft (reverse comment-continue) numarg)))
 	 block
 	 lines
 	 indent))))))
@@ -1360,7 +1358,7 @@ comment-or-uncomment-region
   (interactive "*r\nP")
   (comment-normalize-vars)
   (funcall (if (comment-only-p beg end)
-	       'uncomment-region 'comment-region)
+	       #'uncomment-region #'comment-region)
 	   beg end arg))
 
 ;;;###autoload
@@ -1545,8 +1542,9 @@ comment-indent-new-line
                      (comment-start comstart)
                      (comment-end comend)
                      (continuep (or comment-multi-line
-                                    (cadr (assoc comment-style
-                                                 comment-styles))))
+                                    (null comment-style)
+                                    (cadr (assq comment-style
+                                                comment-styles))))
                      ;; Recreate comment-continue from comment-start.
                      ;; FIXME: wrong if comment-continue was set explicitly!
                      ;; FIXME: use prev line's continuation if available.

bug#50840: 28.0.50; Support GNU style of multiline comments in C source code

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 50840@debbugs.gnu.org,  Alan Mackenzie <acm@muc.de>
> Date: Fri, 01 Oct 2021 15:42:32 -0400
> 
> > It sounds like none of the comment styles in 'comment-styles' can
> > produce the style of C code comments that we use in Emacs, i.e.
> >
> >     /* This is the first line of a multi-line comment.
> >        This is the final line of a multi-line comment.  */
> >
> > And I don't see anything in the CC Mode manual to augment that,
> > either.
> 
> I'm not sure exactly what that would mean in practice.
> `comment-style` is used to comment out code rather than to write the
> text of a comment.  I think what you're asking for is what you get by
> setting `comment-multi-line` and then writing your text (e.g. starting
> with M-; and then typing the text in there, maybe with auto-fill set).

The actual use case is to convert a block of comments like this:

    // First line
    // continuation line with more text,
    // more text.  And another sentence
    // which continues here.

to our comment style.  I thought it was easy: first uncomment the
region, then comment the region using the proper style.  But there's
no style to take a sequence of lines like this:

     First line
     continuation line with more text,
     more text.  And another sentence
     which continues here.

and make it look like this:

     /* First line
        continuation line with more text,
        more text.  And another sentence
        which continues here.  */

> If you want comment-region to produce something like the above, then
> maybe a patch like the following would make sense?

It's late down here, so instead of applying the patch and playing with
it, let me ask you: will this patch support the above use case?

> The idea is to add a new value nil to `comment-style` which would
> instruct `comment-region` to refrain from adding `comment-continue` on
> eachline of a multiline comment.

The value nil doesn't sound like a good mnemonic.  I think the style I
have in mind is a multi-line style, just without the "* " leader on
each line.

Thanks.

bug#50840: 28.0.50; Support GNU style of multiline comments in C source code

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> The actual use case is to convert a block of comments like this:
>
>     // First line
>     // continuation line with more text,
>     // more text.  And another sentence
>     // which continues here.
>
> to our comment style.  I thought it was easy: first uncomment the
> region, then comment the region using the proper style.  But there's
> no style to take a sequence of lines like this:
>
>      First line
>      continuation line with more text,
>      more text.  And another sentence
>      which continues here.
>
> and make it look like this:
>
>      /* First line
>         continuation line with more text,
>         more text.  And another sentence
>         which continues here.  */

Ah, now that makes sense, thanks.

>> If you want comment-region to produce something like the above, then
>> maybe a patch like the following would make sense?
> It's late down here, so instead of applying the patch and playing with
> it, let me ask you: will this patch support the above use case?

I don't think so because it will fail to indent the last 3 lines by the
extra 3 spaces.

>> The idea is to add a new value nil to `comment-style` which would
>> instruct `comment-region` to refrain from adding `comment-continue` on
>> eachline of a multiline comment.
> The value nil doesn't sound like a good mnemonic.  I think the style I
> have in mind is a multi-line style, just without the "* " leader on
> each line.

Right (though you do want to use a leader on each line, just one of "   "
instead of " * "), but `comment-styles` doesn't have a field to specify
that the comment-continuation should be empty, so I was going for
a cheaper solution.

I'll try again later for something less cheap ;-)


        Stefan

bug#50840: 28.0.50; Support GNU style of multiline comments in C source code

[Juri Linkov]

> But there's no style to take a sequence of lines like this:
>
>      First line
>      continuation line with more text,
>      more text.  And another sentence
>      which continues here.
>
> and make it look like this:
>
>      /* First line
>         continuation line with more text,
>         more text.  And another sentence
>         which continues here.  */

Recently lisp/newcomment.el was fixed in bug#47167 and bug#50226
to handle whitespace in 'comment-continue' with the multi-line style.
So you can get the above with:

  (setq-local comment-style 'multi-line
              comment-continue "   ")

PS: It doesn't add double space at the sentence end
since this is a separate feature.

bug#50840: 28.0.50; Support GNU style of multiline comments in C source code

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Recently lisp/newcomment.el was fixed in bug#47167 and bug#50226
> to handle whitespace in 'comment-continue' with the multi-line style.
> So you can get the above with:
>
>   (setq-local comment-style 'multi-line
>               comment-continue "   ")

Seems to work well, so I guess there isn't more to be done here, and I'm
closing this bug report.

> PS: It doesn't add double space at the sentence end
> since this is a separate feature.

Yup.