fsc-0077
Section D., I quote... Tear Line: This sub-field contains a
tearline (not to exceed 35 characters including the
leading "---" characters. This line is required on all
echomail messages.
I have seen some 60+ character tear lines, for example:
"--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125"
tearlines and origin lines and even message body lines have artificial limits placed on them because folks got used to 80x25 terminals... they look very funny when viewed on terminals with larger widths...
Re: Desired Living Document (section): Author Compliance
By: mark lewis to Ozz Nixon on Sat Mar 23 2019 11:37 am
tearlines and origin lines and even message body lines have
artificial
limits placed on them because folks got used to 80x25 terminals... they look very funny when viewed on terminals with larger widths...
*SBBS* has a bug, I just noticed the last two emails I have "quoted" it
is
putting the incorrect initials ... VC should be ML... :-/
Anyway, would it be worth implementing a Kludge for flowed - when found 0d is ignored
and paragraphs get formatted by the reader? This is how JAMNNTPd
works - in my NNTP server code I dropped flowed since it was really messing up BBS_ADS and a couple other echos. I thinking adding ^aFORMAT: flowed^m would help in the cases that people can handle >80 columns.
That would make ^aCOLS: 80^m make a little more sence ;)
tearlines and origin lines and even message body lines have
artificial limits placed on them because folks got used to 80x25
terminals... they look very funny when viewed on terminals with
larger widths...
*SBBS* has a bug, I just noticed the last two emails I have "quoted"
it is putting the incorrect initials ... VC should be ML... :-/
Anyway, would it be worth implementing a Kludge for flowed - when
found 0d is ignored and paragraphs get formatted by the reader? This
is how JAMNNTPd works - in my NNTP server code I dropped flowed since
it was really messing up BBS_ADS and a couple other echos. I thinking adding ^aFORMAT: flowed^m would help in the cases that people can
handle >80 columns.
That would make ^aCOLS: 80^m make a little more sence ;)
i don't care if they only have
40cols to read/write but don't
force that shite on me and my
terminal...
Looks like crap from this angle.
i don't care if they only have
40cols to read/write but don't
force that shite on me and my
terminal...
Amen. BTW the paragraph I quoted the
above from is 562 characters wide and
splits into 4 lines on a 160 character
wide screen. Just for fun this is what
my reply would look like if replying on
a crippled mobile device with shoddy
software that imposes the device's
physical limitations on an entire
network.
Looks like crap from this angle.
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...
Looks like crap from this angle.
I agree. Not all of us are teathered to cell phones.
Should I check or should I post a message to a local area there and
see how that works out?
Amen. BTW the paragraph I quoted the
above from is 562 characters wide and
splits into 4 lines on a 160 character
wide screen. Just for fun this is what
my reply would look like if replying on
a crippled mobile device with shoddy
software that imposes the device's
physical limitations on an entire
network.
Looks like crap from this angle.
Speaking of MBSE, I did manage to login via ssh into the BBS the other day and noticed that the display is cp437 instead of utf8. I went into the user configuration menu to make sure it was set to utf8 and it was/is. I haven't actually done anything there beyond reading messages so I don't know what will happen if I actually post a message with real utf8 characters.
Should I check or should I post a message to a local area there and see how that works out?
I rather like it, it saves a lot of energy on eye movement.
When I found out that UTF8 was supported, I did a minor trial.
Amen. BTW the paragraph I quoted the above from is 562 characters
wide and splits into 4 lines on a 160 character wide screen. Just
for fun this is what my reply would look like if replying on a
crippled mobile device with shoddy software that imposes the device's
physical limitations on an entire network.
Looks like crap from this angle.
I rather like it, it saves a lot of energy on eye movement. ;))
I found that there was also support for Utf8. Due to his knowledge
from day job, he was far ahead of all of us.
Also toying with the idea of replacing joe with nano on there. Do you know if that is easily doable?
Yeah, just modify jpico, joe's emulator of pico. ;)
That would be too easy. Besides that isn't what I asked, but now that
you bring it up I get the impression that it is my system that has to supply a working version of joe in the first place. If that is so
then it seems to me that somewhere there is a configuration for it somewhere in mbse that might be open to replacement of joe with nano
which I know for a fact can handle utf8 characters. I am not too sure about joe but I suppose I can easily find out if indeed I must supply
the working copy that mbse will then use.
Are my above assumtions valid? In the meantime I'll have a looksee at
joe to see if there are any utf8 issues no matter which emulation. I already know that I'll be sticking with vim for everything I do that requires an editor. Nothing beats it.
MBSE uses the joe already installed on the system.
the default full screen editor for use with MBSE
On 2019 Apr 12 03:31:24, you wrote to me:
tearlines and origin lines and even message body lines have
artificial limits placed on them because folks got used to 80x25
terminals... they look very funny when viewed on terminals with
larger widths...
*SBBS* has a bug, I just noticed the last two emails I have "quoted"
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:
Anyway, would it be worth implementing a Kludge for flowed - when
found 0d is ignored and paragraphs get formatted by the reader? This
is how JAMNNTPd works - in my NNTP server code I dropped flowed since it was really messing up BBS_ADS and a couple other echos. I thinking adding ^aFORMAT: flowed^m would help in the cases that people can handle >80 columns.
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?
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?
Sorry, but you don't understand the intention of those control line
then. I'd be happy to discuss it.
mark lewis wrote to Rob Swindell <=-
maybe i don't fully understand it, then... why would i or my terminal
care about the width of the original writer's screen if we're not going
to use that value on our end some how?
On 2019 Apr 14 01:32:20, you wrote to me:
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?
Sorry, but you don't understand the intention of those control line then. I'd be happy to discuss it.
maybe i don't fully understand it, then... why would i or my terminal care about the width of the original writer's screen i
we're not going to use that value on our end some how?
@COLS: 132
Re: Desired Living Document (section): Author Compliance
By: mark lewis to Rob Swindell on Sun Apr 14 2019 09:10 am
On 2019 Apr 14 01:32:20, you wrote to me:
toThat 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
80cols on my 125 character wide terminal?
Sorry, but you don't understand the intention of those control line
then. I'd be happy to discuss it.
maybe i don't fully understand it, then... why would i or my terminal
care about the width of the original writer's screen i we're not going
to use that value on our end some how?
It has nothing to do with artificially restricting anything. It allows an intelligent message viewer (e.g. Synchronet) to re-wrap messages for nice display by knowing the difference between a 39 character line of text that was: a. that length because of the result of a word-wrapping due to being written with a 40 column terminal, or b. that length because the author intended for the line to be short (e.g. drawing a table)
It allows an intelligent viewer to make *more* use of the available columns to display messages while retaining the formatting originally intended (hopefully) by the message's author.
Hello Rob!
15 Apr 19 02:45, you wrote to mark lewis:
@COLS: 132
Re: Desired Living Document (section): Author Compliance
By: mark lewis to Rob Swindell on Sun Apr 14 2019 09:10 am
On 2019 Apr 14 01:32:20, you wrote to me:
toThat 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
80cols on my 125 character wide terminal?
Sorry, but you don't understand the intention of those control line
then. I'd be happy to discuss it.
maybe i don't fully understand it, then... why would i or my terminal
care about the width of the original writer's screen i we're not going
to use that value on our end some how?
It has nothing to do with artificially restricting anything. It allows an intelligent message viewer (e.g. Synchronet) t
re-wrap messages for nice display by knowing the difference between a 39 character line of text that was: a. that length
because of the result of a word-wrapping due to being written with a 40 column terminal, or b. that length because the
author intended for the line to be short (e.g. drawing a table)
It allows an intelligent viewer to make *more* use of the available columns to display messages while retaining the
formatting originally intended (hopefully) by the message's author.
Is not that, why Fidonet makes a distict between a hard and a soft return
0d versus 8d
That's a good question. I haven't see any BBS message editors that
insert a so-called "soft CR" and FTS-1 says they (character 0x8d)
should be ignored
when importing packets, so that whole concept just seems to be an anachronism. Does anyone actuall send/receive "soft CRs"?
Is not that, why Fidonet makes a distict between a hard and a soft
return
0d versus 8d
That's a good question. I haven't see any BBS message editors that insert a so-called "soft CR" and FTS-1 says they (character 0x8d) should be ignored when importing packets, so that whole concept just seems to be an anachronism. Does anyone actuall send/receive "soft CRs"?
0x8d) should be ignored when importing packets, so that whole concept justseems to be an anachronism. Does anyone actually send/receive "soft CRs"?
maybe i don't fully understand it, then... why would i or my terminal
care about the width of the original writer's screen if we're not
going to use that value on our end some how?
Perhaps for formatting reasons such as a table or somesuch? I don't really know either. I'd never heard of the COLS kludge until this conversation.
It allows an intelligent viewer to make *more* use of the available columns to display messages while retaining the formatting originally intended (hopefully) by the message's author.
it is brand new ;)
That's a good question. I haven't see any BBS message editors that insert a so-called "soft CR" and FTS-1 says they (character
0x8d) should be ignored when importing packets, so that whole concept just seems to be an anachronism. Does anyone actuall
send/receive "soft CRs"?
As for semingly useless kludges, many usenet and e-mail gateways preserve a
or many RFC header line in kludges. Nobody complains there.
CRs"?That's a good question. I haven't see any BBS message editors thatinsert a -> so-called "soft CR" and FTS-1 says they (character ->
0x8d)
should be ignored when importing packets, so that whole concept just -> seems to be an anachronism. Does anyone actuall -> send/receive "soft
That's a good question. I haven't see any BBS message editors thatinsert a -> so-called "soft CR" and FTS-1 says they (character ->
0x8d)
should be ignored when importing packets, so that whole concept just
seems to be an anachronism. Does anyone actuall -> send/receive"soft CRs"?
This non standard quoting style works terrible, when requoted... :-(
@TID: hpt/lnx 1.9.0-cur 07-09-15
On 2019 Apr 18 17:48:36, you wrote to OZZ NIXON:
Since we're talking about changing intransit mail in different areas. I noticed something on this message. It arrived here 6 times. On 4 of those there was an empty line between the last kludge and the first line with text as shown above. On 2 this empty line wasn't there...
Path lines with the empty line:
@PATH: 3634/12 320/219 280/5555
@PATH: 3634/12 320/219 221/1
@PATH: 3634/12 320/219 310/31
@PATH: 3634/12 320/219 5020/545
@PATH: 3634/12 154/10
Without:
@PATH: 3634/12 320/219 203/0
@PATH: 3634/12 320/219 240/5832
Is this annoying? Don't think so. Just found it remarkable...
Could you reply with 2 empty lines between the last kludge and your
first line with text?
It would be interesting to see what happens. Will just 1 empty line be removed, or both of them. ;)
Btw: In all of them, your long line was untouched.
no, not annoying but it is against spec...
all posts leaving this system from GoldED have one blank line after the last control line...
no, not annoying but it is against spec...
What spec?
BTW, 2:203/0 is using SquishMail.
mark lewis -> Wilfred van Velzen skrev 2019-04-19 18:29:
all posts leaving this system from GoldED have one blank line after
the last control line...
Any particular reason for this? Just curious...
On 2019 Apr 19 19:18:58, you wrote to me:
no, not annoying but it is against spec...
What spec?
the one that says
ok... what version, please? can you capture packets coming in and those generated after and take a look to see if the message body is being modified by removal of the (blank) line in question?
Any particular reason for this? Just curious...
because that's the way they are formatted when they leave here ;)
no, not annoying but it is against spec...
What spec?
the one that says
blah blah blah. FTS number please, after all this is where we are.
itok... what version, please? can you capture packets coming in and
those generated after and take a look to see if the message body is
being modified by removal of the (blank) line in question?
Negatory. That's the beauty of my system. I have absolutely no means to intercept any message on passthru here. Most importantly -- and far less importantly echomail -- netmail. I take real pride in that and have done
this way for a quarter of a century. YMMV.
Any particular reason for this? Just curious...
because that's the way they are formatted when they leave here ;)
So, you decide what's kosher?
i decide what leavs my systems and what format they are in... if that's ""kosher"" then sobeit...
@TID: hpt/lnx 1.9.0-cur 07-09-15
On 2019 Apr 19 18:10:26, you wrote to me:
it is also interesting... what tossers are running on those two
systems, 203/0 and 240/5832?
Could you reply with 2 empty lines between the last kludge and your
first line with text?
i've added another blank line above...
It would be interesting to see what happens. Will just 1 empty line
be removed, or both of them. ;)
do tell :)
no, not annoying but it is against spec... it is also interesting...
what tossers are running on those two systems, 203/0 and 240/5832?
Could you reply with 2 empty lines between the last kludge and
your first line with text?
i've added another blank line above...
It would be interesting to see what happens. Will just 1 empty
line be removed, or both of them. ;)
do tell :)
Btw: In all of them, your long line was untouched.
that's good :)
no, not annoying but it is against spec... it is also interesting...
what tossers are running on those two systems, 203/0 and 240/5832?
203/0 is Squish 1.11 IIRC. I'm not sure what tosser Torsten is using at 240/5832.
203/0 is Squish 1.11 IIRC. I'm not sure what tosser Torsten is
using at 240/5832.
=== Begin Clipboard ===
Tossing CBAF77EC.PKT from 2:240/5832 to 2:221/360
+-(Squish 1.11, Type 2+) (2 kB, 20-Apr-19 12:42:06)
=== End Clipboard ===
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,047 |
Nodes: | 15 (0 / 15) |
Uptime: | 18:02:17 |
Calls: | 500,823 |
Calls today: | 2 |
Files: | 109,364 |
D/L today: |
1,388 files (420M bytes) |
Messages: | 466,136 |