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).