threads / patch / 44715

patchRe: [PATCH] printk: Remove no longer used second struct cont

Subject: Re: [PATCH] printk: Remove no longer used second struct cont

## tl;dr

3 messages between Dec 16, 2016 and Dec 16, 2016. Diffs are folded; open one to read it.

replies: 2people: 2as markdown or json

Joe Perches· Dec 16, 2016, 02:30 UTC · lore
On Thu, 2016-12-15 at 18:10 -0800, Linus Torvalds wrote:
Show 16 quoted lines
> On Thu, Dec 15, 2016 at 5:57 PM, Joe Perches <joe@perches.com> wrote:
> > > 
> > > In fact, I thought we already upped the check-patch limit to 100?
> > 
> > Nope, CodingStyle neither.
> > 
> > Last time I tried was awhile ago.
> 
> Ok, it must have been just talked about, and with the exceptions for
> strings etc I may not have seen as many of the really annoying line
> breaks lately.
> 
> I don't mind a 80-column "soft limit" per se: if some code
> consistently goes over 80 columns, there really is something seriously
> wrong there. So 80 columns may well be the right limit for that kind
> of check (or even less).
Newspaper column widths were relatively small for a good reason.

I think most of the uses of simple statements should be on a single line. I'd rather see just a few arguments on a single line than a dozen though. Especially those with long identifiers, functions with many arguments are just difficult to visually scan.

Show 15 quoted lines
> But if we have just a couple of lines that are longer (in a file that
> is 3k+ lines), I'd rather not break those.
> 
> I tend use "git grep" a lot, and it's much easier to see function
> argument use if it's all on one line.
> 
> Of course, some function calls really are *so* long that they have to
> be broken up, but that's where the "if it's a couple of lines that go
> a bit over the 80 column limit..." exception basically comes in.
> 
> Put another way: long lines definitely aren't good. But breaking long
> lines has some downsides too, so there should be a balance between the
> two, rather than some black-and-white limit.
> 
> In fact, we've seldom had cases where black-and-white limits work well.

One thing that _would_ be useful is some enhancement to git grep that would look for multi-line statements more easily.

The git grep -P option doesn't span lines.

grep 2.5.4 was the last version that supported the -P option to grep through for multiple lines.

It'd be nice to have something like
	git grep --code_style=c90 --function <foo>

that'd show all multiple line uses/definitions/declarations of a particular function.

I played with extending git grep a bit once, mostly to get the \s mechanism to span lines. It kinda worked.

Still, it seems like real work to implement well.
Joe Perches· Dec 16, 2016, 06:04 UTC · re: Junio C Hamano · lore
On Thu, 2016-12-15 at 21:00 -0800, Junio C Hamano wrote:
Show 6 quoted lines
> Joe Perches <joe@perches.com> writes:
> 
> > grep 2.5.4 was the last version that supported the -P option to
> > grep through for multiple lines.
> 
> Does anybody know why it was dropped?

perl compatible regexes in grep have always been "experimental" and never officially supported.

From the grep manual https://www.gnu.org/software/grep/manual/grep.html
    --perl-regexp
        Interpret the pattern as a Perl-compatible regular expression
    (PCRE). This is highly experimental, particularly when combined with
    the -z (--null-data) option, and ‘grep -P’ may warn of unimplemented
    features. See Other Options.
It wasn't dropped so much as "enhanced" away.
Oh well.

← back to recent threads