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. --- * Origin: (1:3634/12.73)
