All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] printk: Remove no longer used second struct cont
Date: Thu, 15 Dec 2016 17:57:12 -0800	[thread overview]
Message-ID: <1481853432.29291.76.camel@perches.com> (raw)
In-Reply-To: <CA+55aFz3B2BfjG54z7ALOwezCHSdQp+YbFaHcJkCg=fzoKtfNg@mail.gmail.com>

On Thu, 2016-12-15 at 17:50 -0800, Linus Torvalds wrote:
> On Thu, Dec 15, 2016 at 5:37 PM, Sergey Senozhatsky
> <sergey.senozhatsky.work@gmail.com> wrote:
> > 
> > basically I'm talking about a bunch of 80-cols fixups.
> 
> Please don't.
> 
> Nobody uses a vt100 terminal any more. The 80-column wrapping is
> excessive, and makes things like "grep" not work as well.
> 
> No, we still don't want excessively long lines, but that's generally
> mainly because
> 
>  (a) we don't want to have excessively _complicated_ lines
> 
>  (b) we don't want to have excessively deep indentation (so if line
> length is due to 4+ levels of indentation, that's usually the primary
> problem).
> 
>  (c) email quoting gets iffier and uglier, so short lines always are
> preferred if possible
> 
> but in general, aside from those concerns, a long legible line is
> generally preferred over just adding line breaks for the very
> _occasional_ line.
> 
> At the 100-column mark you almost have to break, because at that point
> people may start to be actually limited by their displays, but 80
> columns generally isn't it.
> 
> In fact, I thought we already upped the check-patch limit to 100?

Nope, CodingStyle neither.

Last time I tried was awhile ago.

  reply	other threads:[~2016-12-16  1:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-15 12:53 [PATCH] printk: Remove no longer used second struct cont Geert Uytterhoeven
2016-12-15 16:23 ` Petr Mladek
2016-12-16  1:37   ` Sergey Senozhatsky
2016-12-16  1:39     ` Joe Perches
2016-12-16  1:50       ` Sergey Senozhatsky
2016-12-16  1:50     ` Linus Torvalds
2016-12-16  1:57       ` Joe Perches [this message]
2016-12-16  2:10         ` Linus Torvalds
2016-12-16  2:30           ` Joe Perches
2016-12-16  5:00             ` Junio C Hamano
2016-12-16  6:04               ` Joe Perches
2016-12-16  6:04                 ` Joe Perches
2016-12-16  2:00       ` Sergey Senozhatsky
2016-12-18 19:29       ` Scott Matheina

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=1481853432.29291.76.camel@perches.com \
    --to=joe@perches.com \
    --cc=akpm@linux-foundation.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.