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

-

[ message continues ]

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 

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

-

[ message continues ]

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

-

[ message continues ]

On Wed, 22 Aug 2007 23:54:41 -0400

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
-

[ message continues ]

xclip converts tabs to space if i remember correctly

re,
-

[ message continues ]

On Thu, 23 Aug 2007 13:56:48 +0200

no, it doesn't


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

(middle mouse button)


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

[ message continues ]

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
-

[ message continues ]

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

[ message continues ]

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

see above.

	Cheers,
		Andi
-

[ message continues ]

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

-

[ message continues ]

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
[ message continues ]