-={ Sunday, 06 March 2016, 14:36:13 -0500 }=-

Hey Nicholas!

 NB> Great news!

For sure.  I was happy to see it.

 NB> I haven't applied any patches to 2.5.2 over here, including that
 NB> one.

I just tried it with v2.5.3 and patch gave a slew of errors and it rendered the
source uncompilable due to the wrapping code.  So now I am back to the
unpatched code which is fine with me.  I'll just fix outgoing messages so that
paragraphs are unbounded and not worry about incoming which has basically been
standard operating procedures for many, many years now.  ;-)

Anyhow yours looks perfect here ... so far.

 NB> I'm not sure if it has to do with the BBS being in CP437 mode

That shouldn't matter as long as the internal editor never gets to 'fix' the
outgoing messages originating from nano (or vim).  Old DOS editors are okay as
they don't attempt to 'fix' any character codes and thus the utf8 codes are
preserved albiet wrongly displayed to the user of such limited editors.

 NB> Odd that nano doesn't have any of the issues I'm having with vim
 NB> though.

Sounds odd.  I do know there are no issues with either here on a linux
terminal.

 NB> Any time I've upgraded I just went without it in hopes that
 NB> someday it would be added to the sources. :(

That looks to be the case since v2.5.3 wraps on word boundaries rather than a
set number of characters.  Somewhat like coreutils's "fold -s" app which is the
ultimate viewer on a linux terminal methinks, especially when dealing with utf8
characters.  That is what I have been deploying when reading properly formatted
text messages at this end.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.3.42(1)-release (x86_64-unknown-linux-gnu)