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 / [email protected]
---------------------------------------
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
On Wed, 22 Aug 2007 23:54:41 -0400
"Scott Thompson" <[email protected]> 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
Paolo Ornati wrote:
> On Wed, 22 Aug 2007 23:54:41 -0400
> "Scott Thompson" <[email protected]> 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.
>
On Thu, 23 Aug 2007 13:56:48 +0200
walter harms <[email protected]> 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
On 23/08/07, Scott Thompson <[email protected]> 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 <[email protected]>
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
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.
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
> 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
> 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.
On 24/08/07, Alan Cox <[email protected]> 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 <[email protected]>
---
--- 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 <[email protected]>
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
On Fri, 24 Aug 2007 07:07:54 -0400 Jesper Juhl
<[email protected]> wrote:
>On 24/08/07, Alan Cox <[email protected]> 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 / [email protected]
---------------------------------------
On Fri, 24 Aug 2007 12:31:43 -0400 Scott Thompson wrote:
> On Fri, 24 Aug 2007 07:07:54 -0400 Jesper Juhl
> <[email protected]> wrote:
> >On 24/08/07, Alan Cox <[email protected]> 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 ***
On Thu, 23 Aug 2007 08:27:09 -0400 Jesper Juhl
<[email protected]> 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 / [email protected]
---------------------------------------