Ideas on column length in kernel "problem"?

Ideas on column length in kernel "problem"?

[Scott Thompson]

I haven't seen any recent solutions to this "problem"...

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.  

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 don't have an easy solution short of finding volunteer(s) who can 
submit patches to resolve this or peer-pressuring module owners 
into resolving, so opening this issue up to the list for ideas 
here.  In the meantime I'll run a quick review to assess just how 
many changes this would be ...

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.

---------------------------------------
Scott Thompson / postfail@hushmail.com
---------------------------------------

Re: Ideas on column length in kernel "problem"?

[Adrian Bunk]

On Wed, Aug 22, 2007 at 11:54:41PM -0400, Scott Thompson wrote:
> I haven't seen any recent solutions to this "problem"...
> 
> 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.  
> 
> 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 don't have an easy solution short of finding volunteer(s) who can 
> submit patches to resolve this or peer-pressuring module owners 
> into resolving, so opening this issue up to the list for ideas 
> here.  In the meantime I'll run a quick review to assess just how 
> many changes this would be ...

Most people get it right, so there must be a solution available that
doesn't involve changing the kernel. ;-)

Most likely the problem is that you cut'n'paste your patches into your  
email client (or the editor your email client opens). If your client has 
some "Insert File" functionality use this instead.

> 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.

Open source email clients I have personally used to send patches are 
(al)pine with the included pico as editor and mutt with nano as editor, 
but it might be harder to find ones that don't work than ones that do 
work...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Ideas on column length in kernel "problem"?

[Suresh Jayaraman]

On Wed, Aug 22, 2007 at 11:54:41PM -0400, Scott Thompson wrote:

> > I haven't seen any recent solutions to this "problem"...
> > 
> > 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.

I too had thought about this problem. I think email clients do wordwrap
to improve readability. But, in some cases we just might have to
override. ( I had an experience of sending a malformed patch just
because my wordwrap setting for vim and my email client were different)

What should be ideally expected out of a good email client?
Is it sufficient if the email client provides a facility to disable
wordwrap while inserting file alone and does wordwrap while typing text?
or is it expected to provide a configurable option to enable/disable
wordwrap. I don't think keeping wordwrap disabled all the time is a good
idea because it makes it difficult to read mails.

Do we have a suggested wordwrap setting w.r.t kernel code?

-- 
Suresh Jayaraman

Re: Ideas on column length in kernel "problem"?

[Paolo Ornati]

On Wed, 22 Aug 2007 23:54:41 -0400
"Scott Thompson" <postfail@hushmail.com> wrote:

> 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.

http://www.claws-mail.org/

Configuration -> Preferences -> Wrapping:

"	[x] Auto wrapping
	[ ] Wrap quotation
	[ ] Wrap pasted text

Wrap messages at [..] characters"


Then use the "Insert File" button or (xclip < mypatch.diff && middle
mouse button).

Either will wrap with "Wrap pasted text", so keep it off.


PS: auto wrapping has effect on the text you write directly in the
mailer, you can even turn it off and use "CTRL + L" to wrap the current
paragraph.

-- 
	Paolo Ornati
	Linux 2.6.23-rc3-g2a677896-dirty on x86_64

Re: Ideas on column length in kernel "problem"?

[walter harms]

Paolo Ornati wrote:
> On Wed, 22 Aug 2007 23:54:41 -0400
> "Scott Thompson" <postfail@hushmail.com> wrote:
> 
>> 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.
> 
> http://www.claws-mail.org/
> 
> Configuration -> Preferences -> Wrapping:
> 
> "	[x] Auto wrapping
> 	[ ] Wrap quotation
> 	[ ] Wrap pasted text
> 
> Wrap messages at [..] characters"
> 
> 
> Then use the "Insert File" button or (xclip < mypatch.diff && middle
> mouse button).

xclip converts tabs to space if i remember correctly

re,
 wh




> Either will wrap with "Wrap pasted text", so keep it off.
> 
> 
> PS: auto wrapping has effect on the text you write directly in the
> mailer, you can even turn it off and use "CTRL + L" to wrap the current
> paragraph.
> 

Re: Ideas on column length in kernel "problem"?

[Paolo Ornati]

On Thu, 23 Aug 2007 13:56:48 +0200
walter harms <wharms@bfs.de> wrote:

> xclip converts tabs to space if i remember correctly

no, it doesn't


paolo@tux ~ $ echo -e "\tHello" | xclip

(middle mouse button)

	Hello

:)

-- 
	Paolo Ornati
	Linux 2.6.23-rc3-g2a677896-dirty on x86_64

Re: Ideas on column length in kernel "problem"?

[Jesper Juhl]

On 23/08/07, Scott Thompson <postfail@hushmail.com> wrote:
> I haven't seen any recent solutions to this "problem"...
>
> 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.
>
At least for gmail the wrap problem only exists if you try and use the
web interface for sending your patches. If you use a real mail client
like pine, kmail etc to send your patches through gmail (and remember
to use their read/insert file functionality instead of cut'n'paste)
then there is no problem.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Ideas on column length in kernel "problem"?

[Bron Gondwana]

On Wed, Aug 22, 2007 at 11:54:41PM -0400, Scott Thompson wrote:
> 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.  

<disclaimer>I work for them</disclaimer>

FastMail (http://fastmail.fm/) have a tickbox in the web interface
so you can turn off line-wrapping if you need to.
 
Otherwise, as other people have said, use direct SMTP (we don't allow
it for non-paying accounts, but do for all levels of paying user)
and use a sane local client (in my case mutt+offlineimap)

Bron.

Re: Ideas on column length in kernel "problem"?

[Andi Drebes]

> 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

Re: Ideas on column length in kernel "problem"?

[Alan Cox]

> 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."

As has repeatedly been stated this is a bug in Documentation/CodingStyle
and bears no resemblence to reality. 

Re: Ideas on column length in kernel "problem"?

[Jesper Juhl]

[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]

On 24/08/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > 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."
>
> As has repeatedly been stated this is a bug in Documentation/CodingStyle
> and bears no resemblence to reality.
>
So let's update CodingStyle once and for all so that doesn't pop up
again. See attached patch (inline version is whitespace damaged -
can't help it from my current location).


As continuously gets pointed out, the 80 col line length defined in CodingStyle
is not a hard limit in real life. Let the document reflect reality.

Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

--- Documentation/CodingStyle~  2007-08-24 13:04:20.000000000 +0200
+++ Documentation/CodingStyle   2007-08-24 13:04:20.000000000 +0200
@@ -77,7 +77,8 @@
 Coding style is all about readability and maintainability using commonly
 available tools.

-The limit on the length of lines is 80 columns and this is a hard limit.
+The limit on the length of lines is 80 columns. This is a soft limit, it can
+be broken in some cases, but you should respect it whenever possible.

 Statements longer than 80 columns will be broken into sensible chunks.
 Descendants are always substantially shorter than the parent and are placed



-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

[-- Attachment #2: line-length.patch --]
[-- Type: application/octet-stream, Size: 825 bytes --]


As continuously gets pointed out, the 80 col line length defined in CodingStyle
is not a hard limit in real life. Let the document reflect reality.

Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

--- Documentation/CodingStyle~	2007-08-24 13:04:20.000000000 +0200
+++ Documentation/CodingStyle	2007-08-24 13:04:20.000000000 +0200
@@ -77,7 +77,8 @@
 Coding style is all about readability and maintainability using commonly
 available tools.
 
-The limit on the length of lines is 80 columns and this is a hard limit.
+The limit on the length of lines is 80 columns. This is a soft limit, it can
+be broken in some cases, but you should respect it whenever possible.
 
 Statements longer than 80 columns will be broken into sensible chunks.
 Descendants are always substantially shorter than the parent and are placed

Re: Ideas on column length in kernel "problem"?

[Scott Thompson]

On Fri, 24 Aug 2007 07:07:54 -0400 Jesper Juhl 
<jesper.juhl@gmail.com> wrote:
>On 24/08/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> > 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."
>>
>> As has repeatedly been stated this is a bug in 
>Documentation/CodingStyle and bears no resemblence to reality.
>>

Quite the hornet's nest I've stirred up -- I'm not trying to rock 
the boat, just trying to row.

Meanwhile, I ran a couple programs against the 2.6.22.1 source to 
get some statistics on the source in the linux kernel tree to 
understand what 'reality' is:

Number of files -- 23742
Number of lines > 80 columns:  247057
Number of lines > 90 columns:  127016
Number of lines > 100 columns: 21

The *winner* at 482 columns is a commented out line in

/linux-2.6.22.1/drivers/pci/hotplug/ibmphp_ebda.c 440 //		debug 
("rio_node_id: %x\nbbar: %x\nrio_type: %x\nowner_id: 
%x\nport0_node: %x\nport0_port: %x\nport1_node: %x\nport1_port: 
%x\nfirst_slot_num: %x\nstatus: %x\n", rio_detail_ptr->rio_node_id, 
rio_detail_ptr->bbar, rio_detail_ptr->rio_type, rio_detail_ptr-
>owner_id, rio_detail_ptr->port0_node_connect, rio_detail_ptr-
>port0_port_connect, rio_detail_ptr->port1_node_connect, 
rio_detail_ptr->port1_port_connect, rio_detail_ptr->first_slot_num, 
rio_detail_ptr->status);

So I think updating the text in coding style one way or another is 
a good thing since there are ~248k exceptions to the style rule...

I can make the bins + scripts I used to gather this and output of 
this run available if anyone is interested.

However, this isn't the whole story.. one of the side effects of 
the patch system through email clients are that the function name 
in the 'git diff' (or comparable) output can tack on 20-25 columns 
of header and further cause wordwrap strife and bring more patches 
into this problem.  It *appears* that many maintainers are pretty 
good at recognizing this and purging portions of the function names 
when forwarding them around, but it's still a bigger and common 
'problem' for the wordwrapping clients.

Example: 
@@ -189,6 +189,9 @@ static __devinit int ixp4xx_pata_probe(struct 
platform_device *pdev)

Common advice appears to be to get smtp working on gmail, and I 
thank the list for their suggestions.  If I get one/two ways 
working that are compliant for patch submittal w/o wordwrap (et al) 
I'll start a 'howto' from my notes on yahoo and gmail/smtp setup 
and post that up on the interweb.

---------------------------------------
Scott Thompson / postfail@hushmail.com
---------------------------------------

Re: Ideas on column length in kernel "problem"?

[Randy Dunlap]

On Fri, 24 Aug 2007 12:31:43 -0400 Scott Thompson wrote:

> On Fri, 24 Aug 2007 07:07:54 -0400 Jesper Juhl 
> <jesper.juhl@gmail.com> wrote:
> >On 24/08/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> > 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."
> >>
> >> As has repeatedly been stated this is a bug in 
> >Documentation/CodingStyle and bears no resemblence to reality.
> >>
> 
> Quite the hornet's nest I've stirred up -- I'm not trying to rock 
> the boat, just trying to row.
> 
> Meanwhile, I ran a couple programs against the 2.6.22.1 source to 
> get some statistics on the source in the linux kernel tree to 
> understand what 'reality' is:
> 
> Number of files -- 23742
> Number of lines > 80 columns:  247057
> Number of lines > 90 columns:  127016
> Number of lines > 100 columns: 21
> 
> The *winner* at 482 columns is a commented out line in
> 
> /linux-2.6.22.1/drivers/pci/hotplug/ibmphp_ebda.c 440 //		debug 
> ("rio_node_id: %x\nbbar: %x\nrio_type: %x\nowner_id: 
> %x\nport0_node: %x\nport0_port: %x\nport1_node: %x\nport1_port: 
> %x\nfirst_slot_num: %x\nstatus: %x\n", rio_detail_ptr->rio_node_id, 
> rio_detail_ptr->bbar, rio_detail_ptr->rio_type, rio_detail_ptr-
> >owner_id, rio_detail_ptr->port0_node_connect, rio_detail_ptr-
> >port0_port_connect, rio_detail_ptr->port1_node_connect, 
> rio_detail_ptr->port1_port_connect, rio_detail_ptr->first_slot_num, 
> rio_detail_ptr->status);
> 
> So I think updating the text in coding style one way or another is 
> a good thing since there are ~248k exceptions to the style rule...

We could update CodingStyle, but it's still just a guideline,
not a strict requirement, so how would that fix anything?

> I can make the bins + scripts I used to gather this and output of 
> this run available if anyone is interested.
> 
> However, this isn't the whole story.. one of the side effects of 
> the patch system through email clients are that the function name 
> in the 'git diff' (or comparable) output can tack on 20-25 columns 
> of header and further cause wordwrap strife and bring more patches 
> into this problem.  It *appears* that many maintainers are pretty 
> good at recognizing this and purging portions of the function names 
> when forwarding them around, but it's still a bigger and common 
> 'problem' for the wordwrapping clients.

diff -p output is preferred for diffs (for review).
I'm not aware of people purging that info.

> Example: 
> @@ -189,6 +189,9 @@ static __devinit int ixp4xx_pata_probe(struct 
> platform_device *pdev)
> 
> Common advice appears to be to get smtp working on gmail, and I 
> thank the list for their suggestions.  If I get one/two ways 
> working that are compliant for patch submittal w/o wordwrap (et al) 
> I'll start a 'howto' from my notes on yahoo and gmail/smtp setup 
> and post that up on the interweb.

Thanks.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: Ideas on column length in kernel "problem"?

[Scott Thompson]

On Thu, 23 Aug 2007 08:27:09 -0400 Jesper Juhl 
<jesper.juhl@gmail.com> wrote:
>
>At least for gmail the wrap problem only exists if you try and use 
>the
>web interface for sending your patches. If you use a real mail 
>client
>like pine, kmail etc to send your patches through gmail (and 
>remember
>to use their read/insert file functionality instead of 
>cut'n'paste)
>then there is no problem.

I submitted a patch via gmail/smtp after setting the following up 
and all looked well...

gmail --> settings --> forwarding and pop --> enable pop.

directions for setting up thunderbird:
Thunderbird 1.5
http://mail.google.com/support/bin/answer.py?answer=38343

configuring Thunderbird for wordwrap:
Edit -> Preferences -> Composition
Wrap Plain Text Messages at: 99999

.... and that's it...

I'm gathering up a list of free email clients + settings and will 
post a link once a copy is up on the interweb.

---------------------------------------
Scott Thompson / postfail@hushmail.com
---------------------------------------