{"thread":{"id":"44715","subject":"Re: [PATCH] printk: Remove no longer used second struct cont","startedAt":"2016-12-16T02:41:08Z","lastAt":"2016-12-16T06:05:05Z","messageCount":3,"participants":["Joe Perches","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"307881","messageId":"1481855446.29291.80.camel@perches.com","threadId":"44715","inReplyTo":"CA+55aFxaOFoh+Zrm5tNhU4hWu4Z032+nqV3vXK=QPJyhZsU3_A@mail.gmail.com","subject":"Re: [PATCH] printk: Remove no longer used second struct cont","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2016-12-16T02:30:46Z","receivedAt":"2016-12-16T02:41:08Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Thu, 2016-12-15 at 18:10 -0800, Linus Torvalds wrote:\n> On Thu, Dec 15, 2016 at 5:57 PM, Joe Perches <joe@perches.com> wrote:\n> > > \n> > > In fact, I thought we already upped the check-patch limit to 100?\n> > \n> > Nope, CodingStyle neither.\n> > \n> > Last time I tried was awhile ago.\n> \n> Ok, it must have been just talked about, and with the exceptions for\n> strings etc I may not have seen as many of the really annoying line\n> breaks lately.\n> \n> I don't mind a 80-column \"soft limit\" per se: if some code\n> consistently goes over 80 columns, there really is something seriously\n> wrong there. So 80 columns may well be the right limit for that kind\n> of check (or even less).\n\nNewspaper column widths were relatively small for a good reason.\n\nI think most of the uses of simple statements should be on a single\nline.  I'd rather see just a few arguments on a single line than a\ndozen though.  Especially those with long identifiers, functions\nwith many arguments are just difficult to visually scan.\n\n> But if we have just a couple of lines that are longer (in a file that\n> is 3k+ lines), I'd rather not break those.\n> \n> I tend use \"git grep\" a lot, and it's much easier to see function\n> argument use if it's all on one line.\n> \n> Of course, some function calls really are *so* long that they have to\n> be broken up, but that's where the \"if it's a couple of lines that go\n> a bit over the 80 column limit...\" exception basically comes in.\n> \n> Put another way: long lines definitely aren't good. But breaking long\n> lines has some downsides too, so there should be a balance between the\n> two, rather than some black-and-white limit.\n> \n> In fact, we've seldom had cases where black-and-white limits work well.\n\nOne thing that _would_ be useful is some enhancement to git grep\nthat would look for multi-line statements more easily.\n\nThe git grep -P option doesn't span lines.\n\ngrep 2.5.4 was the last version that supported the -P option to\ngrep through for multiple lines.\n\nIt'd be nice to have something like\n\tgit grep --code_style=c90 --function <foo>\n\nthat'd show all multiple line uses/definitions/declarations of a\nparticular function.\n\nI played with extending git grep a bit once, mostly to get the \\s\nmechanism to span lines.  It kinda worked.\n\nStill, it seems like real work to implement well.\n"},{"id":"307883","messageId":"xmqqtwa4tqnc.fsf@gitster.mtv.corp.google.com","threadId":"44715","inReplyTo":"1481855446.29291.80.camel@perches.com","subject":"Re: [PATCH] printk: Remove no longer used second struct cont","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-16T05:00:07Z","receivedAt":"2016-12-16T05:00:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joe Perches <joe@perches.com> writes:\n\n> grep 2.5.4 was the last version that supported the -P option to\n> grep through for multiple lines.\n\nDoes anybody know why it was dropped?\n"},{"id":"307884","messageId":"1481868265.29291.84.camel@perches.com","threadId":"44715","inReplyTo":"xmqqtwa4tqnc.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] printk: Remove no longer used second struct cont","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2016-12-16T06:04:25Z","receivedAt":"2016-12-16T06:05:05Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Thu, 2016-12-15 at 21:00 -0800, Junio C Hamano wrote:\n> Joe Perches <joe@perches.com> writes:\n> \n> > grep 2.5.4 was the last version that supported the -P option to\n> > grep through for multiple lines.\n> \n> Does anybody know why it was dropped?\n\nperl compatible regexes in grep have always been \"experimental\"\nand never officially supported.\n\nFrom the grep manual https://www.gnu.org/software/grep/manual/grep.html\n\n    --perl-regexp\n\n        Interpret the pattern as a Perl-compatible regular expression\n    (PCRE). This is highly experimental, particularly when combined with\n    the -z (--null-data) option, and ‘grep -P’ may warn of unimplemented\n    features. See Other Options.\n\n\nIt wasn't dropped so much as \"enhanced\" away.\n\nOh well.\n\n"}]}