From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: acm@muc.de, Stefan Monnier <monnier@iro.umontreal.ca>,
50840@debbugs.gnu.org
Subject: bug#50840: 28.0.50; Support GNU style of multiline comments in C source code
Date: Mon, 27 Sep 2021 18:35:50 +0000 [thread overview]
Message-ID: <YVIPButhDTcjBE1S@ACM> (raw)
In-Reply-To: <837df2moym.fsf@gnu.org>
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).
next prev parent reply other threads:[~2021-09-27 18:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-27 7:56 bug#50840: 28.0.50; Support GNU style of multiline comments in C source code Eli Zaretskii
2021-09-27 18:35 ` Alan Mackenzie [this message]
2021-09-27 18:51 ` Eli Zaretskii
2021-09-29 11:04 ` Alan Mackenzie
2021-09-29 12:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-29 17:30 ` Alan Mackenzie
2021-10-01 19:42 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-01 19:50 ` Eli Zaretskii
2021-10-01 20:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-03 17:02 ` Juri Linkov
2022-09-02 10:59 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YVIPButhDTcjBE1S@ACM \
--to=acm@muc.de \
--cc=50840@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).