-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Would the long List-* header fields be more attractive and easier to read if they were folded something like the following?
List-Subscribe: <http://www.python.org/mailman/listinfo/mailman-developers>, <mailto:mailman-developers-request@python.org?subject=subscribe> List-Unsubscribe: <http://www.python.org/mailman/listinfo/mailman-developers>, <mailto:mailman-developers-request@python.org?subject=unsubscribe>
Perhaps folding after the comma would be OK unless the whole field is not greater than, say, 78 characters?
jam-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (GNU/Linux) Comment: OpenPGP encrypted mail preferred. See <http://www.gnupg.org/>
iEYEARECAAYFAjnUnu8ACgkQUEvv1b/iXy9sBQCdEyGhXrxIs/9Vkpcc31wOPn7e iE8AoJPTJaw6bTSBHD1+TU5KNZVcs/ij =jNfW -----END PGP SIGNATURE-----
At 09:53 AM 9/29/00 -0400, John A. Martin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Would the long List-* header fields be more attractive and easier to read if they were folded something like the following?
List-Subscribe: <http://www.python.org/mailman/listinfo/mailman-developers>, <mailto:mailman-developers-request@python.org?subject=subscribe> List-Unsubscribe: <http://www.python.org/mailman/listinfo/mailman-developers>, <mailto:mailman-developers-request@python.org?subject=unsubscribe>
Perhaps folding after the comma would be OK unless the whole field is not greater than, say, 78 characters?
Umm, the headers *are* folded.. In the very note that arrived from you, they were folded that way. Unless a friendly MTA on the way to me folded them for me, or unfolded them for you...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
"RJ" == Ron Jarrell "Re: [Mailman-Developers] List-* header suggestion" Fri, 29 Sep 2000 10:32:06 -0400
>> Would the long List-* header fields be more attractive and
>> easier to read if they were folded something like the
>> following?
>>
>> List-Subscribe: <http://www.python.org/mailman/listinfo/mailman-developers>,
>> <mailto:mailman-developers-request@python.org?subject=subscribe>
>> List-Unsubscribe: <http://www.python.org/mailman/listinfo/mailman-developers>,
>> <mailto:mailman-developers-request@python.org?subject=unsubscribe>
>> Perhaps folding after the comma would be OK unless the whole
>> field is not greater than, say, 78 characters?
RJ> Umm, the headers *are* folded.. In the very note that arrived
RJ> from you, they were folded that way. Unless a friendly MTA on
RJ> the way to me folded them for me, or unfolded them for you...I meant _folding a mail header field_ as described in rfc822 section 3.1.1. Standards compliant MTAs won't fold or unfold a header field that it does not itself create. The header fields in question are not now folded. Perhaps your MUA wraps long lines.
jam-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (GNU/Linux) Comment: OpenPGP encrypted mail preferred. See <http://www.gnupg.org/>
iEYEARECAAYFAjnUsOoACgkQUEvv1b/iXy8LnwCfU7HopG5jPE0Eo4iD/B2YkYpo UFMAn3SQBt+/BYiOaM2K7QmUohMbjMBb =JWKu -----END PGP SIGNATURE-----
At 11:11 AM 9/29/00 -0400, John A. Martin wrote:
I meant _folding a mail header field_ as described in rfc822 section 3.1.1. Standards compliant MTAs won't fold or unfold a header field that it does not itself create. The header fields in question are not now folded. Perhaps your MUA wraps long lines.
I looked in my raw mbox file, and they're folded...
Umm, the headers *are* folded.. In the very note that arrived from you, they were folded that way. Unless a friendly MTA on the way to me folded them for me, or unfolded them for you...
they aren't on my site, ron -- it' spossible you have an MTA that *is* folding them for you. Does it do laundry, too?
Folding them would be a good idea, IMHO.
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
You seem a decent fellow. I hate to die.
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> they aren't on my site, ron -- it' spossible you have an MTA CVR> that *is* folding them for you. Does it do laundry, too? CVR> Folding them would be a good idea, IMHO. Me too. Here's the patch. -Barry -------------------- snip snip -------------------- Index: CookHeaders.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/CookHeaders.py,v retrieving revision 1.15 diff -u -r1.15 CookHeaders.py --- CookHeaders.py 2000/09/25 13:40:19 1.15 +++ CookHeaders.py 2000/10/05 19:42:51 @@ -17,6 +17,7 @@ """Cook a message's Subject header. """ +import string import re import urlparse from Mailman import mm_cfg @@ -115,6 +116,11 @@ # one copy of each, and we want to be sure it's ours. for h, v in headers.items(): del msg[h] + # Wrap these lines if they are too long. 78 character width probably + # shouldn't be hardcoded. The adding of 2 is for the colon-space + # separator. + if len(h) + 2 + len(v) > 78: + v = string.join(string.split(v, ', '), ',\n\t') msg[h] = v # # Always delete List-Archive header, but only add it back if the list is
At 09:32 AM 9/29/2000, Ron Jarrell wrote:
At 09:53 AM 9/29/00 -0400, John A. Martin wrote:
Would the long List-* header fields be more attractive and easier to read if they were folded something like the following?
List-Subscribe: <http://www.python.org/mailman/listinfo/mailman-developers>, <mailto:mailman-developers-request@python.org?subject=subscribe> List-Unsubscribe: <http://www.python.org/mailman/listinfo/mailman-developers>, <mailto:mailman-developers-request@python.org?subject=unsubscribe>
Perhaps folding after the comma would be OK unless the whole field is not greater than, say, 78 characters?
Umm, the headers *are* folded.. In the very note that arrived from you, they were folded that way. Unless a friendly MTA on the way to me folded them for me, or unfolded them for you...
It might be a client issue. Using Eudora I can resize the message window to my heart's content and it will fold the lines as appropriate. Is the issue the indentation of the second line so that the header names are the only part flush against the left? The wrapped lines are flush left in my client, so the lines that they wrap to do not begin with the header name but instead begin mid line where the break occurred. I can see John's point that it is not really pretty.
--chris
participants (5)
-
bwarsaw＠beopen.com -
Christopher Kolar -
Chuq Von Rospach -
John A. Martin -
Ron Jarrell