public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Simon Arlott <simon@fire.lp0.eu>
Cc: Denis Cheng <crquan@gmail.com>,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] run scripts/Lindent on it to match Documentation/CodingStyle
Date: Fri, 20 Jul 2007 11:33:22 -0600	[thread overview]
Message-ID: <20070720173322.GG14791@parisc-linux.org> (raw)
In-Reply-To: <4699EEA9.6070709@simon.arlott.org.uk>

On Sun, Jul 15, 2007 at 10:53:45AM +0100, Simon Arlott wrote:
> > -	} else if (base_addr > 0x100) { /* Check a single specified location. */
> > +	} else if (base_addr > 0x100) {	/* Check a single specified location. */
> 
> What is Lit doing here?! It's changed "{<space>/*" to "{<tab>/*"...
> 
> > -	} else { /* Scan all possible addresses of the WaveLAN hardware. */
> > +	} else {		/* Scan all possible addresses of the WaveLAN hardware. */
> 
> And again... with two tabs for maximum unreadability. That line is now
> 90 characters long instead of 75.

There's two things going on here.  One is that we haven't told indent to
cram the comments after code up against the code -- by default it will
move the comment out to start in column 33.  We can override that by
adding '-c1' to the Lindent line.

The other is that, even when you do that, it only wants to indent
comments with tabs.  So in this example:

int bar(void)
{
        if (x) {
        } else if (quite_a_long_conditional_which) { /* takes up a lot of ram */
        } else { /* An absolutely gargantuan comment that heads to the end */
        } /* Another comment */
}

by default Lindent will move the comment to:

        } else if (quite_a_long_conditional_which) {    /* takes up a lot of ram */
        } else {                /* An absolutely gargantuan comment that heads to the end */
        }                       /* Another comment */

adding -c1 gets us:

        } else if (quite_a_long_conditional_which) {    /* takes up a lot of ram */
        } else {        /* An absolutely gargantuan comment that heads to the end */
        }       /* Another comment */

but the indent manpage is quite definite:

       If the code to the left of the comment exceeds  the  beginning  column,
       the comment column will be extended to the next tabstop column past the
       end of the code, or in the case  of  preprocessor  directives,  to  one
       space past the end of the directive.

I suppose someone could add a new option to indent to change that, but
I'd rather see people not put comments there, tbh.

> > -				       "%s: <-wavelan_probe()\n",
> > -				       dev->name);
> > +				       "%s: <-wavelan_probe()\n", dev->name);
> 
> There are spaces in that line after the tabs...

I think that's to make it line up with the beginning of the function arguments.
Can't tell cos you snipped that bit ;-)

-- 
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

      parent reply	other threads:[~2007-07-20 17:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-15  8:52 [PATCH 1/2] run scripts/Lindent on it to match Documentation/CodingStyle Denis Cheng
2007-07-15  8:52 ` [PATCH 2/2] add static delaration and init_module fixes Denis Cheng
2007-07-15  9:20 ` [PATCH 1/2] run scripts/Lindent on it to match Documentation/CodingStyle Christoph Hellwig
2007-07-15  9:53 ` Simon Arlott
2007-07-20 17:07   ` Matthew Wilcox
2007-07-20 17:36     ` Simon Arlott
2007-07-20 18:00       ` Matthew Wilcox
2007-07-21  6:11         ` Simon Arlott
2007-07-21 13:47           ` rae l
2007-07-21 13:52           ` Matthew Wilcox
2007-07-21 19:17             ` diffutils: C labels misdetected as functions (Was: [PATCH 1/2] run scripts/Lindent on it to match Documentation/CodingStyle) Simon Arlott
2007-07-22 18:38               ` diffutils: C labels misdetected as functions Paul Eggert
2007-07-22 19:16                 ` Simon Arlott
2007-07-22 21:30                   ` Junio C Hamano
2007-07-21  6:12         ` [PATCH 1/2] run scripts/Lindent on it to match Documentation/CodingStyle Simon Arlott
2007-07-20 20:50     ` Oleg Verych
2007-07-20 20:54       ` Matthew Wilcox
2007-07-21  4:32         ` Fixing lables after GNU indent (Re: [PATCH 1/2] run scripts/Lindent on it to match Documentation/CodingStyle) Oleg Verych
2007-07-21 16:17     ` [PATCH 1/2] run scripts/Lindent on it to match Documentation/CodingStyle Jan Engelhardt
2007-07-20 17:33   ` Matthew Wilcox [this message]

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070720173322.GG14791@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=crquan@gmail.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=simon@fire.lp0.eu \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox