eli@zgavva.ima.isc.com (Elias Israel) (03/07/90)
Pardon me if the details are fuzzy and for tossing the original patch in the first place, but I seem to recall that someone had posted a patch for mh6.6 that fixed the bug that caused it to put components in the middle of lines when fgets returned only part of a line. Specifically, if you set the body component to '>' in your format file for replies, you'd sometimes get lines that looked like this: >some text from the original letter. Some more text> yet another bit of text That second '>' in the line above is what I'm talking about.. Can anyone help? Thanks, Elias Israel | "Justice, n. A commodity which in more Interactive Systems Corp. | or less adulterated condition the State Boston, MA | sells to the citizen as a reward for his eli@ima.ima.isc.com | allegiance, taxes, and personal service." | -- Ambrose Bierce, The Devil's Dictionary
tim@appenzell.cs.wisc.edu (Tim Theisen) (03/12/90)
In article <16102@haddock.ima.isc.com> eli@zgavva.ima.isc.com (Elias Israel) writes: >Pardon me if the details are fuzzy and for tossing the original patch in >the first place, but I seem to recall that someone had posted a patch >for mh6.6 that fixed the bug that caused it to put components in the >middle of lines when fgets returned only part of a line. > >Specifically, if you set the body component to '>' in your format file >for replies, you'd sometimes get lines that looked like this: > >>some text from the original letter. Some more text> yet another bit of text > >That second '>' in the line above is what I'm talking about.. > >Can anyone help? Sure! I found the problem when I started using mh last year. Here is a copy of the message that I sent to MH-Bugs. I found a problem with mhl in the way that it handles the body of a message. I used to following for a filter to repl: body:component="> " Messages over 1024 (BUFSIZ) bytes long would have "> " inserted in the middle of some lines. This was caused by the fact the mhl would print the component text at the beginning of each buffer. I changed the way that the HDROUTPUT flag was handled for BODY components. Previously, HDROUTPUT was never set for BODY components. So when the second buffer was printed, it would print the header again (Usually in the middle of the line). I set the HDROUTPUT flag when the first header is printed. I also removed the erroneous check for HDROUTPUT at the beginning of each new line. If you have any questions about this fix please contact me. Tim Theisen Department of Computer Sciences tim@cs.wisc.edu University of Wisconsin-Madison uwvax!tim 1210 West Dayton Street (608)262-0438 Madison, WI 53706 Here are the diffs that correct the problem: *** /tmp/,RCSt1000334 Tue Mar 21 13:35:51 1989 --- mhlsbr.c Tue Mar 21 13:29:53 1989 *************** *** 1204,1209 **** --- 1204,1211 ---- while (count--) putstr (" "); } + else + c1 -> c_flags |= HDROUTPUT; } if (flag == TWOCOMP *************** *** 1245,1251 **** if (*cp) { lm = count; if (flag == BODYCOMP - && !(c1 -> c_flags & HDROUTPUT) && !(c1 -> c_flags & NOCOMPONENT)) putstr (c1 -> c_text ? c1 -> c_text : c1 -> c_name); putstr (cp); --- 1247,1252 ---- -- Tim Theisen Department of Computer Sciences tim@cs.wisc.edu University of Wisconsin-Madison uwvax!tim 1210 West Dayton Street (608)262-0438 Madison, WI 53706