Subj : Re: EDIT text editor
To   : Jimmy Day
From : William McBrine
Date : Mon Dec 02 2002 10:53 am

-=> Jimmy Day wrote to William McBrine <=-

 WM> After seeing Jimmy Day's posted messages, one possible common factor
 WM> that comes to mind is letting MultiMail do the wrapping, instead of
 WM> the editor. (I'm guessing, based only on the fact that Jimmy's
 WM> messages appear to be wrapped at 80 columns.) For those who've
 WM> encountered this problem: Are you doing that?

 JD> I checked my MM config file and the wrap is set to 78, not 80.

No, no, no. The setting you're referring to in mmail.rc is "QuoteWrapCols",
which is only applied to quoted material. I'm talking about the original
material you type yourself. There's no setting to control that; you either
wrap it in your text editor, or (when in QWK mode) it will be wrapped
automatically by MultiMail at 80 columns. This isn't adjustable. But if you
wrap it from within the text editor at 80 columns or less, then MultiMail's
wrapping function doesn't come into play.

So this is what I'm asking you: Since I know that you use(d) Notepad as
your text editor, did you tell it to word-wrap? IIRC, word-wrap is off by
default in that editor; and I saw that your replies were wrapped at 80
columns. So did MultiMail wrap them, or did Notepad? (Usually, if one were
wrapping within the text editor, the margin would be less than 80; but I'm
not sure what margin Notepad uses, or whether it's adjustable.)

(Later, after testing:) You know what? Never mind... I can't get Notepad to
actually save with word-wrap, even when word-wrap is selected -- it seems
to affect only the display. And there's nowhere to change the margin. So,
it MUST be MultiMail that wrapped it. I thought as much... but I'd still
like to hear from the others who've had this problem.

 JD> The "strip soft carriage returns (char. 141)" is set to NO, which 
 JD> appears to me to apply to reading messages, not writing them?

Yes.

 JD> If you give me the all-clear, I will timidly use MM, with fingers
 JD> crossed...

I can't give you the "all-clear", since I haven't yet nailed down the
problem, nor released a fix. (Though if you don't mind compiling it
yourself, the version that's in CVS now should be safe from this problem.)

What seems to be happenning is that the padding routine writes out one too
few spaces. I suspect that this happens ONLY when the word-wrapping is left
to MultiMail, and probably only on DOSish systems -- the ones that use CRLF
to delimit lines in native text files, instead of just LF as on Unix. But
it doesn't ALWAYS happen even then; in fact, I've so far been unable to
construct a test case that would elicit the observed behavior.

The changes I've made cause the padding routine to check the actual length
of the file on disk, instead of the calculated length that the message
_should_ have, so it should never fall short again. But I still don't know
how the problem arises, and I'd prefer to understand (and fix) that before
I put out an update. If it takes much longer, though, I'll have to.

.... All that glitters has a high index of refraction.
--- MultiMail/Linux v0.44
 * Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

.