On 2019 Apr 12 03:31:24, you wrote to me:

 VC>> tearlines and origin lines and even message body lines have
 VC>> artificial limits placed on them because folks got used to 80x25
 VC>> terminals... they look very funny when viewed on terminals with
 VC>> larger widths...

 ON> *SBBS* has a bug, I just noticed the last two emails I have "quoted"
 ON> it is putting the incorrect initials ... VC should be ML... :-/

nope... that bug is in the editor that xxcarol has in place... she was told 
about the bug and the fix years ago... she still hasn't taken care of it by 
installing the updated/fixed editor :shrug:

 ON> Anyway, would it be worth implementing a Kludge for flowed - when
 ON> found 0d is ignored and paragraphs get formatted by the reader? This
 ON> is how JAMNNTPd works - in my NNTP server code I dropped flowed since
 ON> it was really messing up BBS_ADS and a couple other echos. I thinking
 ON> adding ^aFORMAT: flowed^m would help in the cases that people can
 ON> handle >80 columns.

 ON> That would make ^aCOLS: 80^m make a little more sence ;)

i don't know... i understand it for what it is intended to be used for but why 
do i want to display a message artifically restricted to 80cols on my 125 
character wide terminal? why can't it just be displayed out to 125 instead of 
squashed to the left? that's like in one of the mailing lists i/we read, 
someone is apparently using a mobile device at times because their posts are 
all squashed left into 40cols or less... that's just rediculous... i don't care 
if they only have 40cols to read/write but don't force that shite on me and my 
terminal...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it 
wrong...
... You know, just like real life.
---