fseditor.js has been tested at various terminal widths. It word-wraps the created message text based on the current terminal width (less than or greater than 80 is no problem), so we need to store the terminal width in order to nicely re-word-wrap the message when being view or quoted by a user with a different terminal size.
Re: Word wrapping
By: Digital Man to Nightfox on Thu Apr 11 2019 05:25 pm
fseditor.js has been tested at various terminal widths. It word-wraps the
created message text based on the current terminal width (less than or greater than 80 is no problem), so we need to store the terminal width in
order to nicely re-word-wrap the message when being view or quoted by a user with a different terminal size.
I am experimenting with a local copy of SlyEdit that allows typing the message in the entire width of the terminal (rather than restricting it to 79 characters). I'm curious if this message comes across okay and looks good, and what happens when this message is quoted.
I am experimenting with a local copy of SlyEdit that allows typing the message
in the entire width of the terminal (rather than
restricting it to 79 characters). I'm curious if this message comes across okay and looks good, and what happens when this message
is quoted.
I am experimenting with a local copy of SlyEdit that allows typing the message
in the entire width of the terminal (rather than
restricting it to 79 characters). I'm curious if this message comes across okay and looks good, and what happens when this message
is quoted.
The above is what I see in BBBS when I view your message. I hope it doesn't get
reformatted. I'm not sure why it wraps on the second line after the word "than
and on the forth line after the word "message".
I've been wondering if it makes sense to always word-wrap at 79 columns.
I am experimenting with a local copy of SlyEdit that allows typing the message in the entire width of the terminal (rather than restricting it to 79 characters). I'm curious if this message comes across okay and looks good, and what happens when this message is quoted.
@MSGID: 1:153/757.0 d3596bb7doesn't
@REPLY: 38099.syncprog@1:103/705 2115ccd6
@TZUTC: -0800
@CHARSET: LATIN-1
I am experimenting with a local copy of SlyEdit that allows typing the
message in the entire width of the terminal (rather than restricting it to
79 characters). I'm curious if this message comes across okay and looks
good, and what happens when this message is quoted.
The above is what I see in BBBS when I view your message. I hope it
get reformatted. I'm not sure why it wraps on the second line after the word "than and on the forth line after the word "message".
Just FYI. :)
--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
SEEN-BY: 10/0 1 14/5 15/0 2 19/36 34/999 90/1 102/401 103/705 116/18 120/302
SEEN-BY: 120/331 123/1970 153/135 250 757 6809 7715 154/10 203/0 214/22 218/0
SEEN-BY: 218/1 210 215 401 520 640 700 221/0 226/17 229/107 354 426 452 1014
SEEN-BY: 230/150 152 240/5832 249/206 317 400 250/1 261/38 100 266/512 267/155
SEEN-BY: 275/100 280/464 5003 282/1031 1056 290/10 291/1 111 320/119 219 SEEN-BY: 322/757 342/200 393/68 396/45 423/120 712/848 801/161 189 3634/12 SEEN-BY: 5020/932 1042 123/25 150 3634/50 119 123/50 3634/0 18/0 123/0 1/120
@PATH: 153/757 393/68 229/426 280/464 103/705 218/700 261/38 3634/12
And btw, I'm viewing your message here in 80-colums and it displayed like so: -8<- The above is what I see in BBBS when I view your message. I hope it doesn't get reformatted. I'm not sure why it wraps on the second line after the word "than and on the forth line after the word "message". -8<-
I'm not sure if that's reformatted from the original or not.
I've been wondering if it makes sense to always word-wrap at 79
columns.
No.
IMHO messages should be wrapped at time of output.
There's no need to insert line breaks for some arbitrary terminal
width when they could instead be inserted as appropriate for the
viewing terminal.
Looks great on Vertrauen (viewing at 80 cols). And I can see from the message header you were using a terminal width of 132 columns at the time you wrote it.
I am experimenting with a local copy of SlyEdit that allows typing the
message in the entire width of the terminal (rather than
restricting it to 79 characters). I'm curious if this message comes
across okay and looks good, and what happens when this message
is quoted.
The above is what I see in BBBS when I view your message. I hope it doesn't get
reformatted. I'm not sure why it wraps on the second line after the word "than and on the forth line after the word "message".
output where? from the editor into the temporary disk file? from the file
i think you're saying the same thing i have been saying... don't put in soft-cr or hard-cr as line endings... use hard-cr only for paragraph termination... if you're drawing a table or chart, sure, put hard-crs at
your own tosser doesn't reformat them, either... it is absolutely up to the reading terminal to determine where to wrap message test while displaying it before quoting it in a reply or follow-up...
I've been wondering if it makes sense to always word-wrap at 79
columns.
No. IMHO messages should be wrapped at time of output. There's no need to insert line breaks for some arbitrary terminal width when they could instead be inserted as appropriate for the viewing terminal.
restricting it to 79 characters). I'm curious if this message comes
across okay and looks good, and what happens when this message is
quoted.
there is still wrapping being forced in the transmitted message :(
my terminal is currently 165x54...
http://sestar.synchro.net/temp/20190412-nightfox-echomail-experiment-01.jp g
it would be a lot better if there was no forced wrapping and my terminal was allowed to wrap according to its extents... i thought we were trying to get away from forced wrapping in transmitted messages and allow the remote side to wrap to its size/settings... somehow this looks to be going backwards...
quoted wrapping (aka reflow) is another thing...
http://sestar.synchro.net/temp/20190412-nightfox-echomail-experiment-0
1.jpg
it would be a lot better if there was no forced wrapping and my
terminal was allowed to wrap according to its extents... i thought we
were trying to get away from forced wrapping in transmitted messages
and allow the remote side to wrap to its size/settings... somehow this
looks to be going backwards...
quoted wrapping (aka reflow) is another thing...
Yeah, I was thinking quoted wrapping wouldn't really work very well due to the added characters at the front of the lines,
so I don't think I will support quoted line wrapping.
However, I noticed the message I typed does look like it's longer than
79 characters, just that it's not wrapping for the full width of the terminal you're using.
What BBS software are you using?
Because he wrote it with a terminal in 132 column mode and you're viewing it in a terminal likely in 80 column mode.
And btw, I'm viewing your message here in 80-colums and it displayed like so: -8<-
The above is what I see in BBBS when I view your message. I hope it doesn't ge >reformatted. I'm not sure why it wraps on the second line after the word "than
and on the forth line after the word "message".
-8<-
I'm not sure if that's reformatted from the original or not.
something along the below path rewrapped your post in the same manner we have
been talking about in ASIAN_LINK with maurice... it was easily seen before the >quoting because of the leading space added to the lines after the first one...
look at this image...
http://sestar.synchro.net/temp/20190412-TRMB-echomail-intermediate-reformattin
-01.jpg
i'll bet that there is at least system similar to 153/250 in the above path...
You had mentioned yesterday that you added a setting in SCFG to enable sending >the terminal width in the message header. I didn't have that setting yet sinc >the new Synchronet binaries weren't available.. So is that setting enabled by >default in the older builds? Also, I see there are no new Synchronet binaries
available today.. The latest sbbs_dev.zip is dated April 11th.
hmm.. I suspect only Synchronet BBSes will re-wrap based on the terminal widt
in the message header.
i'll bet that there is at least system similar to 153/250 in the above
path...
Yes there is. That stuff is all front and center now so we'll get that info to James. I'm thinking now that I'll try and get some stuff for
you to look at in your e-test area when we have some upgrades to
check.
it is actually quite easy along with reflow... the problem is what to reflow... without any soft-crs or hard-crs, life is much easier... only put hard-crs at the end of a paragraph...
so I don't think I will support quoted line wrapping.
reflowing...
it isn't a BBS... it is GoldED, a sysop reader that i use on this point system to access the message areas stored in JAM bases and managed by the HPT tosser ;)
is that setting enabled by default in the older builds? Also, I see
there are no new Synchronet binaries available today.. The latest
sbbs_dev.zip is dated April 11th.
Your message has a COLS kludge that says "COLS: 80". Is your terminal 80 characters wide?
The above is what I see in BBBS when I view your message. I hope it
doesn't get
reformatted. I'm not sure why it wraps on the second line after the
word "than
and on the forth line after the word "message".
Because he wrote it with a terminal in 132 column mode and you're viewing it in a terminal likely in 80 column mode.
IMHO messages should be wrapped at time of output.
output where? from the editor into the temporary disk file? from the file into the BBS? from the BBS into a FTN PKT? between BBSes?
Re: Word wrapping
By: Nightfox to Digital Man on Thu Apr 11 2019 15:10:04
I've been wondering if it makes sense to always word-wrap at 79 columns.
No. IMHO messages should be wrapped at time of output. There's no need to insert line breaks for some arbitrary terminal width when they could instead be
inserted as appropriate for the viewing terminal.
it is actually quite easy along with reflow... the problem is what to
reflow... without any soft-crs or hard-crs, life is much easier...
only put hard-crs at the end of a paragraph...
so I don't think I will support quoted line wrapping.
reflowing...
What is "reflowing"?
it isn't a BBS... it is GoldED, a sysop reader that i use on this
point system to access the message areas stored in JAM bases and
managed by the HPT tosser ;)
Ah. Well I'm not sure how Synchronet handles line wrapping when using GoldEd.
I suspect Synchronet does its line wrapping when a user is logged in
to the BBS and viewing messages that way.
Since GoldEd reads the message database directly, I suspect GoldEd is probably doing is own line wrapping.
@VIA: VERT/DIGDIST
@MSGID: <5CB00154.19072.dove_syncprog@digitaldistortionbbs.com>
@REPLY: <5CAFDAF8.38098.syncprog@vert.synchro.net>
Re: Word wrapping
By: Digital Man to Nightfox on Thu Apr 11 2019 05:25 pm
fseditor.js has been tested at various terminal widths. It word-wraps the created message text based on the current terminal width (less than or greater than 80 is no problem), so we need to store the terminal width in order to nicely re-word-wrap the message when being view or quoted by a user with a different terminal size.
I am experimenting with a local copy of SlyEdit that allows typing the message in the entire width of the terminal (rather than restricting it
to 79 characters). I'm curious if this message comes across okay and looks good, and what happens when this message is quoted.
Nightfox
---
■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
What is "reflowing"?
where the existing quotes are reflowed to fit when the new quote characters are added...
Since GoldEd reads the message database directly, I suspect GoldEd
is probably doing is own line wrapping.
it is... the problem is when editors stuff CRs into the message in an effort to wrap them... those CRs are left in the messages when they are brought back into the BBS for others to access locally or remotely via message network transports... it would be nice if editors could somehow remove those forced wrapping CRs before the BBS imports the message into the message base... that or the BBS would remove them... so that then
I'm also jumping in with a thought that pop'ed up in my head while reading this Topic about 40, 80 and 132 character limits used with computer data.
It may be preferable to store all messages un-wrapped and then optionally wrap/re-wrap messages exported to specific networks (or echoes) at the time of export, based on sysop's configuration preferences (e.g. network requirements). That way, local msg areas or those exported to known-compatible nets could pass around un-wrapped text.
It may be preferable to store all messages un-wrapped and then
optionally wrap/re-wrap messages exported to specific networks (or
echoes) at the time of export, based on sysop's configuration
preferences (e.g. network requirements). That way, local msg areas or
those exported to known-compatible nets could pass around un-wrapped
text.
I was wondering about that, if text in a message should be saved as
one long line
Yes there is. That stuff is all front and center now so we'll get that
info to James. I'm thinking now that I'll try and get some stuff for
you to look at in your e-test area when we have some upgrades to
check.
ok... please also check that netmails are not getting origin lines added to them...
i had one come in here from a mystic system that caused sbbsecho to fall over... the actual reason for the fall over hasn't been determined yet but
it definitely falls and there was definitely a proper tear line along with an unnecessary/unwanted/unspeced origin line...
)\/(ark
Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... A mighty creature is the germ, though smaller than the pachyderm.
ok... please also check that netmails are not getting origin lines
added to them...
They do have a tear and origin line when written in Mystic. I don't
know why that is and I have never questioned it. I don't think my BBBS adds a tear or origin line when I send netmail but I'd have to check
an outgoing pkt to be sure.
i had one come in here from a mystic system that caused sbbsecho to
fall over... the actual reason for the fall over hasn't been determined
yet but it definitely falls and there was definitely a proper tear line
along with an unnecessary/unwanted/unspeced origin line...
My first visit with Mystic was around 2015 with one of the 1.11 alphas
and it has always added the tear and origin line to netmail messages
since then.
There may be a netmail issue between Mystic and SBBS but I have never noticed it before. We'd need to have a closer look and see if there
are any needfull things there.
Is it bad in any way that Mystic includes the tear and origin lines in netmail?
them, either... it is absolutely up to the reading terminal to determine where to wrap message test while displaying it before quoting it in a reply or follow-up...
Re: Word wrapping
By: Digital Man to Nightfox on Thu Apr 11 2019 08:16 pm
Looks great on Vertrauen (viewing at 80 cols). And I can see from the message header you were using a terminal width of 132 columns at the time you wrote it.
Thanks for confirming.
You had mentioned yesterday that you added a setting in SCFG to enable sending the terminal width in the message header. I didn't have that setting yet since the new Synchronet binaries weren't available.. So is that setting enabled by default in the older builds?
Also, I see there are
no new Synchronet binaries available today.. The latest sbbs_dev.zip is dated April 11th.
Re: Word wrapping
By: Al to Nightfox on Fri Apr 12 2019 12:05 am
I am experimenting with a local copy of SlyEdit that allows typing the
message in the entire width of the terminal (rather than
restricting it to 79 characters). I'm curious if this message comes
across okay and looks good, and what happens when this message
is quoted.
The above is what I see in BBBS when I view your message. I hope it doesn't get
reformatted. I'm not sure why it wraps on the second line after the word "than and on the forth line after the word "message".
hmm.. I suspect only Synchronet BBSes will re-wrap based on the terminal width in the message header.
quoted wrapping (aka reflow) is another thing...
Yeah, I was thinking quoted wrapping wouldn't really work very well due to the added characters at the front of the lines, so I don't think I will support quoted line wrapping.
On 2019 Apr 12 09:55:26, you wrote to me:
http://sestar.synchro.net/temp/20190412-nightfox-echomail-experiment-0
1.jpg
it would be a lot better if there was no forced wrapping and my
terminal was allowed to wrap according to its extents... i thought we
were trying to get away from forced wrapping in transmitted messages
and allow the remote side to wrap to its size/settings... somehow this
looks to be going backwards...
quoted wrapping (aka reflow) is another thing...
Yeah, I was thinking quoted wrapping wouldn't really work very well due to the added characters at the front of the lines,
it is actually quite easy along with reflow... the problem is what to reflow...
without any soft-crs or hard-crs, life is much easier... only put hard-crs at the end of a paragraph...
so I don't think I will support quoted line wrapping.
reflowing...
However, I noticed the message I typed does look like it's longer than 79 characters, just that it's not wrapping for the full width of the terminal you're using.
right... because of the hard-crs at the ends of those lines...
What BBS software are you using?
it isn't a BBS... it is GoldED, a sysop reader that i use on this point system to access the message areas stored in JAM bases and managed by the HPT tosser ;)
Re: Word wrapping
By: Digital Man to Al on Fri Apr 12 2019 02:09 am
The above is what I see in BBBS when I view your message. I hope it
doesn't get
reformatted. I'm not sure why it wraps on the second line after the
word "than
and on the forth line after the word "message".
Because he wrote it with a terminal in 132 column mode and you're viewing it in a terminal likely in 80 column mode.
I thought the idea, though, was that the terminal width shouldn't matter, and Synchronet should word-wrap the text to be appropriate for the user's terminal width?
right... and that's kinda what we're talking about... sync knows what the user's terminal dimentions are so it can inject CRs where needed but it may not
even have to do that depending on how intelligent the terminal is... some terminals know when to back up to a space and inject a CR so the line moves down one and back to the left margin...
Re: Re: Word wrapping
By: Ed Vance to Nightfox on Fri Apr 12 2019 10:49 am
I'm also jumping in with a thought that pop'ed up in my head while reading this Topic about 40, 80 and 132 character limits used with computer data.
I started using BBSes in 1992, and at least since then, the minimum width I've seen for BBS terminal software has been 80 characters. It seems 80x24 or 80x25 has been a sort of standard for a long time.
the only real difference between echomail and netmail is the
^Aechotag control line... other differences are:
them, either... it is absolutely up to the reading terminal to
determine where to wrap message test while displaying it before
quoting it in a reply or follow-up...
I don't know of any terminal programs that perform word-wrapping.
it is actually quite easy along with reflow... the problem is what to
reflow... without any soft-crs or hard-crs, life is much easier... only
put hard-crs at the end of a paragraph...
What's you're definition of a "soft-cr" and "hard-cr"? I don't know of a any universally accepted definition.
FidoNet's FTS-1 defines a soft-cr as 0x8d (that's an ASCII carriage
return with the high bit, bit-7, set) and it says these characters
should be ignored.
SBBSecho strips all so-called soft-cr 0x8d and 0x0a (line-feed)
characters when importing messages, based on the recommendations of
FTS-1.
it isn't a BBS... it is GoldED, a sysop reader that i use on this point
system to access the message areas stored in JAM bases and managed by
the HPT tosser ;)
Do you know if GoldED(+) actually supports the concept of "soft-cr"
and "hard-cr"? Someone should take a look at that source... :-)
The current implemented idea is that messages are stored using
whatever line-length/wrapping that the message editor created.
Messages imported from networks are not re-formatted either - they are stored "as is" (with exceptions for stripping characters that are
supposed to be ignored/stripped).
I think it would be better to store each paragraph as a single long
line, with caveats:
1. Legacy message editors typically insert line-endings (i.e. CRLF) at
the end of each line (not paragraph), even lines that were
auto-wrapped. So messages created using editors like these would need
to be unwrapped by SBBS (it does not do this currently).
2. I'm not sure how nicely *all* other BBS programs and offline
message readers would display such overly-long lines. It could be
possible to word-wrap upon export messages on a per user (e.g. for
offline reading) or per message network/echo basis, as needed to accomodate unfriendly software.
the only real difference between echomail and netmail is the ^Aechotag
control line... other differences are:
I know that was likely just a typo, but it's "AREA:" and there's no ^A.
On 2019 Apr 13 15:49:50, you wrote to Nightfox:
The current implemented idea is that messages are stored using
whatever line-length/wrapping that the message editor created.
Messages imported from networks are not re-formatted either - they are stored "as is" (with exceptions for stripping characters that are supposed to be ignored/stripped).
ahhh... the other definition of "ignored" ;)
yeah, there's been a bit of discussion over the years about what "ignored" really means... some code totally "ignores" 0x8d which leads to it being stripped... other code "ignores" 0x8d by treating it like any other character and not doing anything specific because of it...
I think it would be better to store each paragraph as a single long line, with caveats:
YAY!
1. Legacy message editors typically insert line-endings (i.e. CRLF) at the end of each line (not paragraph), even lines that were auto-wrapped. So messages created using editors like these would need to be unwrapped by SBBS (it does not do this currently).
i would leave them alone and see about getting the user to upgrade to a newer modern editor that doesn't shove \r at the end of every line... that's been the
movement in fidonet since the early '90s at least...
2. I'm not sure how nicely *all* other BBS programs and offline
message readers would display such overly-long lines. It could be possible to word-wrap upon export messages on a per user (e.g. for offline reading) or per message network/echo basis, as needed to accomodate unfriendly software.
i'm not personally aware of any out of all the fido oriented software i've used
over the years... i've not done QWK stuff in a long time but the tools i have used didn't have any problems that i recall... these days i would use multimail
instead of old abandoned QWK or BW software, though...
i would leave them alone and see about getting the user to upgrade to a
newer modern editor that doesn't shove \r at the end of every line...
that's been the movement in fidonet since the early '90s at least...
Most editors use line-feeds to mark the ends of lines. On a DOS and Windows, that's traditionally be expanded to carriage-return /
line-feed pairs, but I don't recall ever seeing an editor that just
puts bare CRs in text files.
Anyway, "newer modern editors" are always the user or sysops favorite,
so I usually endevor to support old stuff the best I can.
2. I'm not sure how nicely *all* other BBS programs and offline
message readers would display such overly-long lines. It could be
possible to word-wrap upon export messages on a per user (e.g. for
offline reading) or per message network/echo basis, as needed to
accomodate unfriendly software.
i'm not personally aware of any out of all the fido oriented software
i've used over the years... i've not done QWK stuff in a long time
but the tools i have used didn't have any problems that i recall...
these days i would use multimail instead of old abandoned QWK or BW
software, though...
You lost me. Aware of what?
You had mentioned yesterday that you added a setting in SCFG to enable
sending the terminal width in the message header. I didn't have that
setting yet since the new Synchronet binaries weren't available.. So
is that setting enabled by default in the older builds?
It depends what you mean by "older", that behavior is pretty new and was originally implemented for all editors, now it's optional and defaults to off.
I don't think SlyEdit is using the quotes.txt file. Maybe it should? Or at least use the built-in word-wrap function in Synchronet?
You lost me. Aware of what?
"other BBS programs and offline message readers" that have problems to "display
such overly-long lines."
everything i've seen and worked with wraps on its own... sometimes it isn't done well and the text has a "chainsaw" look to it... in FTNs, the movement has
been to abandon forced wrapping in the locally written and stored messages... that translates to long-line-paragraphs in transmission when those messages are
scanned out and sent to other systems... the majority of posts, at one time, were all long-line-paragraph types... i haven't done any analysis in recent years, though, so that may have swung back the other way as systems have dropped out of the networks... i have no idea how QWK stuff is done, though... it may still need that forced wrapping stuff but FTN surely doesn't and has been advancing forward away from it since the '90s...
Re: Word wrapping
By: Digital Man to Nightfox on Sat Apr 13 2019 03:26 pm
You had mentioned yesterday that you added a setting in SCFG to enable
sending the terminal width in the message header. I didn't have that
setting yet since the new Synchronet binaries weren't available.. So
is that setting enabled by default in the older builds?
It depends what you mean by "older", that behavior is pretty new and was originally implemented for all editors, now it's optional and defaults to off.
By "older" I meant before the April 11th build.
I also see another option that says "Word-wrap Quoted Text". I hadn't noticed that option before, but it looks like that option may have been there quite a while. How does it identify quoted text?
Re: Word wrapping
By: Digital Man to Nightfox on Sat Apr 13 2019 03:30 pm
I don't think SlyEdit is using the quotes.txt file. Maybe it should? Or at least use the built-in word-wrap function in Synchronet?
Yes, SlyEdit uses quotes.txt.
I think that's the only way an editor can enable quoting a message?
here's the beginning of another paragraph. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus dictum iaculis leo eget accumsan. Integer ac lectus eget felis dictum dictum. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed quis risus eu elit laoreet luctus. Aliquam erat volutpat. Phasellus pretium posuere libero, at gravida leo accumsan nec. Curabitur lacinia iaculis elementum. Suspendisse rutrum felis lorem, eget maximus lectus condimentum eget. Nam eu metus eget augue condimentum rutrum eget quis orci. Vivamus placerat tortor eget bibendum euismod. Nulla viverra tellus in tellus malesuada commodo. Cras vestibulum sagittis orci, commodo gravida augue accumsan ut. Interdum et malesuada fames ac ante ipsum primis in faucibus. and here's the end of this one paragraph...
here's the beginning of another paragraph. Lorem ipsum dolor sit amet,consectetur adipiscing elit. Phasellus dictum iaculis
leo eget accumsan. Integer ac lectus eget felis dictum dictum. Lorem ipsumdolor sit amet, consectetur adipiscing elit. Sed
quis risus eu elit laoreet luctus. Aliquam erat volutpat. Phasellus pretiumposuere libero, at gravida leo accumsan nec.
Curabitur lacinia iaculis elementum. Suspendisse rutrum felis lorem, egetmaximus lectus condimentum eget. Nam eu metus eget
augue condimentum rutrum eget quis orci. Vivamus placerat tortor egetbibendum euismod. Nulla viverra tellus in tellus
malesuada commodo. Cras vestibulum sagittis orci, commodo gravida augueaccumsan ut. Interdum et malesuada fames ac ante ips
primis in faucibus. and here's the end of this one paragraph...
everything i've seen and worked with wraps on its own... sometimes it isn'tdone well and the text has a "chainsaw" look to
it... in FTNs, the movement has been to abandon forced wrapping in thelocally written and stored messages... that translates
to long-line-paragraphs in transmission when those messages are scanned outand sent to other systems...
Yes, SlyEdit uses quotes.txt.
Ah, that it has its own re-word-wrapping.
I think that's the only way an editor can enable quoting a message?
I was think it was pulling it from the MsgBase, but fine that it doesn't. But the re-word-wrapping of the quotes.txt file shouldn't be necessary (ideally).
You lost me. Aware of what?
"other BBS programs and offline message readers" that have problems
to "display such overly-long lines."
If that's the case, that's great news. I'll have to conduct some experiments.
systems... the majority of posts, at one time, were all
long-line-paragraph types... i haven't done any analysis in recent
years, though, so that may have swung back the other way as systems
have dropped out of the networks... i have no idea how QWK stuff is
done, though... it may still need that forced wrapping stuff but FTN
surely doesn't and has been advancing forward away from it since the
'90s...
Looks like my wrap-quote feature needs some work too! :-(
[trim]here's the beginning of another paragraph. Lorem ipsum dolor sit
ac ante ipsum primis in faucibus. and here's the end of this one
paragraph...
So... that paragraph was received ever over FidoNet as multiple <80 col lines:
Now SMB storage does store line-endings ("hard-CRs" or FidoNet) as CRLF(0d
0a) pairs, but it certainly doesn't break long lines. Are you sure your paragraph was sent out as one overly-long line?
This is just a test. Quoting your message in 132 column mode.
everything i've seen and worked with wraps on its own... sometimes it
isn't done well and the text has a "chainsaw" look to it... in FTNs,
the movement has been to abandon forced wrapping in the locally
written and stored messages... that translates to
long-line-paragraphs in transmission when those messages are scanned
out and sent to other systems...
I'm very curious then why your messages that are received here over FidoNet seem to consistent of lines of 79 chars or less, not "long-line-paragraphs".
i'll be finding out shortly when i quit out of GoldED and grab the outbound packet before it gets over to sestar and sbbsecho gets hold
of it ;)
if you get that original message and it has \n at <80, please post the PATHline... thanks!
if you get that original message and it has \n at <80, please post the
PATH line... thanks!
Here you go: X-FTN-PATH 3634/12 154/10 280/464
if you get that original message and it has \n at <80, please post the
PATH line... thanks!
Here you go: X-FTN-PATH 3634/12 154/10 280/464
3634/12 is, of course, my sbbs node...
154/10 is nick boel's system... looks like he's running sbbs 3.17... 280/464 is wilfred van Velzen's system... i'm pretty sure his tosser is FMail...
i hope it isn't FMail because that's a pretty nice package but if it is, then this problem has gotten a bit larger than earlier suspected :/
i hope it isn't FMail because that's a pretty nice package but if it
is, then this problem has gotten a bit larger than earlier suspected
:/
Is this about reformatting long lines of in transit echomail?
FMail doesn't do that. But you don't have to take my word for it.
Maurice Kinal has tested this ad nauseam from his point address on my system in ASIAN_LINK, as you are well aware of... ;)
| Sysop: | Kurt Hamm |
|---|---|
| Location: | Columbia, SC |
| Users: | 5 |
| Nodes: | 20 (0 / 20) |
| Uptime: | 116:09:50 |
| Calls: | 2,414 |
| Files: | 64 |
| Messages: | 796,841 |
