This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: comments formatting [Re: [patch] physname regression: Non-matching type false breakpoint]
> OK (in VIM it is gq} or gqip ). I use 79 columns instead of 70.
> So in the case of 70 columns what would be the right formatting of:
>
> /* The strchr check is there if any types were specified verify the single found found parameter types really match those specified by user in COPY. */
This is not a quote of my text, I wrote:
/* The strchr check is there if any verify the single found found parameter foo types really match those specified by user in COPY. */
It (c-fill-paragraph) will reformat it correctly, comment starting at
column 0:
/* The strchr check is there if any verify the single found found
parameter foo types really match those specified by user in
COPY. */
Starting at column 8:
/* The strchr check is there if any verify the single found
found parameter foo types really match those specified by
user in COPY. */
This applies only to the C mode though, since it takes care to look at
how comments start and end; the normal text function, fill-paragraph,
does not do that and pretends that a closing comment signature is just
a normal word. In which case it would format it like so (column 0):
/* The strchr check is there if any verify the single found found
parameter foo types really match those specified by user in COPY.
*/
> It would be the one I produced in the previous email:
The text I provided was specially crafted to hit the same problem
with 70 columns as I faced with the 79 columns and as I / others
will face in the future.
When the GNU Coding Standard does describe the comments formatting
rules one has to unfortunately reverse engineer them from Emacs.
I think that the dangling */ on a single line is a cosmetic thing that
hasn't been thought of that much; it looks ugly to have it on a single
line.