mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Phil Carmody <phil.carmody@partner.samsung.com>
Cc: apw@canonical.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] checkpatch: fix some whitespace issues caused by --fix
Date: Tue, 06 Aug 2013 07:09:26 -0700	[thread overview]
Message-ID: <1375798166.2424.12.camel@joe-AO722> (raw)
In-Reply-To: <000901ce927b$c5b74c80$5125e580$%carmody@partner.samsung.com>

On Tue, 2013-08-06 at 11:05 +0300, Phil Carmody wrote:
> > On Mon, 2013-08-05 at 14:08 +0300, Phil Carmody wrote:
> > > Lines with incorrect spacing around an operator, such as:
> > >   bystander, correct,incorrect
> > > would get "fixed" to
> > >   bystander,correct, incorrect
> > > as the correct argument as well as the incorrectly-spaced operator
> > > were both being trimmed. The correct argument only needs to be right
> > > trimmed.
> > 
> > Thanks for the patch, but I think it needs a different fix.
> 
> I think it's the right approach, but you're right,
> fix all the problems. However, in part that's because many 
> copies of the string, or bits of it, are created, and when 
> one copy is modified, the others don't replicate that change.
> 
> > Even after your patch the --fix option still makes a mess of several
> > code spacing issues.
> 
> Indeed. Just seen - func(foo,&bar); becoming func(foo,  &bar);, 
> as --fix wants to put a space both after the ',' and before the '&'.

Hi Phil.

Basically, checkpatch needs to left trim the
"$fix_elements[$n + 2])" if it exists.

> > I'll work on it and propose something soonish.
> 
> It's very much a WIP - I'll send my bride-of-checkpatch to you 
> as soon as I've written some blurb. It might be that the 
> complexities inside checkpatch can't be overcome, and it's
> easier to address the changes entirely in a separate script?

Maybe, but humans are lazy.

Maybe the "bride-of" approach will work better,
It's hard to know right now.  No worries, you try
yours too and one or the other or both might be
the "right" approach.

btw:

The biggest complexity might be handling patches
that need lines added or removed by rewriting
the patch contexts.

Maybe creating an interdiff would be better than
rewriting the patch or file.

I was too lazy to do that to checkpatch for a
first pass.



      reply	other threads:[~2013-08-06 14:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-05 11:08 Phil Carmody
2013-08-06  1:00 ` Joe Perches
2013-08-06  8:05   ` Phil Carmody
2013-08-06 14:09     ` Joe Perches [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=1375798166.2424.12.camel@joe-AO722 \
    --to=joe@perches.com \
    --cc=apw@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phil.carmody@partner.samsung.com \
    /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

all inboxes | Powered by JetHome®