All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Drebes <lists-receive@programmierforen.de>
To: postfail@hushmail.com
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: Ideas on column length in kernel "problem"?
Date: Fri, 24 Aug 2007 10:31:52 +0000	[thread overview]
Message-ID: <200708241231.52767.lists-receive@programmierforen.de> (raw)
In-Reply-To: <20070823035442.6FD0DDA81F@mailserver7.hushmail.com>

> Many free (and not-free) mail clients wordwrap.  Hushmail wraps at 
> 68 (verified), Yahoo has options to wrap at a max of 99, and Gmail 
> was somewhere around 85-90 as I recall.  Not sure on other free / 
> inexpensive clients.  
It happens so often that people send mangled patches that it might be useful 
to create a wiki page or something with the most common email clients and a 
sample configuration that prevents them from mangling patches. Maybe somebody 
feels like doing so in his / her spare time.
 
> However, several code modules have code lines with column lengths 
> well over 80 (the worst I have seen was 211).  This prevents people 
> with "minimal function" email clients (I'm being generous) from 
> making changes in the area of these long code lines, or from even 
> submitting fixes for the line length problem in modules themselves.
I think this is also a matter of conding style. Documentation/CodingStyle 
says:

"The limit on the length of lines is 80 columns and this is a hard limit."

So actually there shouldn't be any line longer than that. Perhaps it would be 
nice to create a patches that shorten the lines and to send them to the 
kernel-janitors ml.

<snip>
> Note -- I am well aware that us 'poor users' could just 'get a real 
> email service', and if anyone knows of a free/inexpensive mail 
> client that will be able to handle the wordwrap requirements for 
> the current state of the linux tree please advise.
see above.

	Cheers,
		Andi

WARNING: multiple messages have this Message-ID (diff)
From: Andi Drebes <lists-receive@programmierforen.de>
To: postfail@hushmail.com
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: Ideas on column length in kernel "problem"?
Date: Fri, 24 Aug 2007 12:31:52 +0200	[thread overview]
Message-ID: <200708241231.52767.lists-receive@programmierforen.de> (raw)
In-Reply-To: <20070823035442.6FD0DDA81F@mailserver7.hushmail.com>

> Many free (and not-free) mail clients wordwrap.  Hushmail wraps at 
> 68 (verified), Yahoo has options to wrap at a max of 99, and Gmail 
> was somewhere around 85-90 as I recall.  Not sure on other free / 
> inexpensive clients.  
It happens so often that people send mangled patches that it might be useful 
to create a wiki page or something with the most common email clients and a 
sample configuration that prevents them from mangling patches. Maybe somebody 
feels like doing so in his / her spare time.
 
> However, several code modules have code lines with column lengths 
> well over 80 (the worst I have seen was 211).  This prevents people 
> with "minimal function" email clients (I'm being generous) from 
> making changes in the area of these long code lines, or from even 
> submitting fixes for the line length problem in modules themselves.
I think this is also a matter of conding style. Documentation/CodingStyle 
says:

"The limit on the length of lines is 80 columns and this is a hard limit."

So actually there shouldn't be any line longer than that. Perhaps it would be 
nice to create a patches that shorten the lines and to send them to the 
kernel-janitors ml.

<snip>
> Note -- I am well aware that us 'poor users' could just 'get a real 
> email service', and if anyone knows of a free/inexpensive mail 
> client that will be able to handle the wordwrap requirements for 
> the current state of the linux tree please advise.
see above.

	Cheers,
		Andi

  parent reply	other threads:[~2007-08-24 10:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-23  3:54 Ideas on column length in kernel "problem"? Scott Thompson
2007-08-23  3:54 ` Scott Thompson
2007-08-23  4:05 ` Adrian Bunk
2007-08-23  4:05   ` Adrian Bunk
2007-08-24  8:17   ` Suresh Jayaraman
2007-08-24  8:29     ` Suresh Jayaraman
2007-08-23  7:36 ` Paolo Ornati
2007-08-23  7:36   ` Paolo Ornati
2007-08-23 11:56   ` walter harms
2007-08-23 11:56     ` walter harms
2007-08-23 12:00     ` Paolo Ornati
2007-08-23 12:00       ` Paolo Ornati
2007-08-23 12:27 ` Jesper Juhl
2007-08-23 12:27   ` Jesper Juhl
2007-08-24  1:43 ` Bron Gondwana
2007-08-24  1:43   ` Bron Gondwana
2007-08-24 10:31 ` Andi Drebes [this message]
2007-08-24 10:31   ` Andi Drebes
2007-08-24 10:46   ` Alan Cox
2007-08-24 10:46     ` Alan Cox
2007-08-24 11:07     ` Jesper Juhl
2007-08-24 11:07       ` Jesper Juhl
2007-08-24 16:31 ` Scott Thompson
2007-08-24 16:31   ` Scott Thompson
2007-08-24 16:51   ` Randy Dunlap
2007-08-24 16:51     ` Randy Dunlap
2007-08-24 19:09 ` Scott Thompson
2007-08-24 19:09   ` Scott Thompson

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=200708241231.52767.lists-receive@programmierforen.de \
    --to=lists-receive@programmierforen.de \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=postfail@hushmail.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 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.