earl wrote:
On Tue, May 13, 2014 at 10:16 PM, Ken Hornstein wrote:
I am unclear as to the right solution. Obviously adjusting the MIME
parsing routines is wrong. Making sure that the last character of
text/plain parts on output contains a newline might be better, but I'm
not sure that's technically right either.
Pagers like 'less' do this. If the file being viewed does not end in a LF,
'less' will add a break so the 'less' status line is still rendered at the
bottom of the terminal window on its own line.
Vim does something similar, but will have "[noeol]" in the status line to
indicate the the source file does not have a EOL sequence at the end.
Since adding a LF would only be done whe rendering the content, and it is
not modifying the original data, I see no problem.
the easy thing to do would be to always add an extra newline in front
of the part marker, but that will cause an extraneous newline in most
cases. the more clever thing to do would be to only add it if the
previous part didn't end in a newline, but that's perhaps a bit hard,
since the previous part was displayed by other code, far far away.
how about this: when the last character of a text/plain part isn't a
newline, append the contents of yet-another-mh-format-script, which by
default would be a just a newline. that would be retain
technical-correctness while supplying expected aesthetics. people
that care can change the newling to output "WARNING-EOM-WITHOUT-NEWLINE"
if they wish.
paul
--ewh
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
=----------------------
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 42.6 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers