What do you guys think about potentially supporting "style codes" in message body text?
I got the idea from reading about GoldEd+'s ability to (optionally) highlight message text that has been marked-up (e.g. this would *bold*, /italic/, etc.). GoldEd+ doesn't actually supports bold, italic, etc., so it just uses different foreground colors to indicate those text styles. But its possible some terminals do support those text attributes and other methods of message rendering (e.g. via HTML/CSS) could definitely support those text attributes.
There are many styles of text mark-up, so I'm not really proposing a specific one (though, compatiblity with GoldEd+'s "style codes") would seem to make sense), but just a basic set, like bold, italic, underline, and inverse. No fonts or sizes or any meaning/context-implications.
Such a feature could be toggleable per sub-board, so if it were a problem for some systems/networks/areas, it'd be easy to turn off. Anyway, something to think about/discuss...
digital man
Synchronet/BBS Terminology Definition #89:
XSDK = Synchronet External Program Software Development Kit for C/C++
Norco, CA WX: 92.5�F, 18.0% humidity, 6 mph NE wind, 0.00 inches rain/24hrs
What do you guys think about potentially supporting "style codes" in message body text?
I got the idea from reading about GoldEd+'s ability to (optionally) highlight message text that has been marked-up (e.g. this would
*bold*, /italic/, etc.). GoldEd+ doesn't actually supports bold,
italic, etc., so it just uses different foreground colors to indicate those text styles. But its possible some terminals do support those
text attributes and other methods of message rendering (e.g. via
HTML/CSS) could definitely support those text attributes.
What do you guys think about potentially supporting "style codes" in message body text?
I got the idea from reading about GoldEd+'s ability to (optionally) highlight message text that has been marked-up (e.g. this would *bold*, /italic/, etc.). GoldEd+ doesn't actually supports bold, italic, etc., so it just uses different foreground colors to indicate those text styles.
Re: Style codes in messages
By: Digital Man to All on Thu Oct 15 2020 05:14 pm
What do you guys think about potentially supporting "style codes" in message body text?
I got the idea from reading about GoldEd+'s ability to (optionally) highlight message text that has been marked-up (e.g. this would *bold*, /italic/, etc.). GoldEd+ doesn't actually supports bold, italic, etc., so it just uses different foreground colors to indicate those text styles.
Interesting idea. Seems to me new changes like this can lead to text potentially looking a bit ugly in clients & readers that don't support those new things, so that's probably something to consider too. I imagine SyncTerm would be updated to support it, but other terminal programs & offline message readers, etc. might not know how to deal with it.
On 10-15-20 17:14, Digital Man wrote to All <=-
What do you guys think about potentially supporting "style codes" in message body text?
I got the idea from reading about GoldEd+'s ability to (optionally) highlight message text that has been marked-up (e.g. this would *bold*, /italic/, etc.). GoldEd+ doesn't actually supports bold, italic, etc.,
so it just uses different foreground colors to indicate those text
styles. But its possible some terminals do support those text
attributes and other methods of message rendering (e.g. via HTML/CSS) could definitely support those text attributes.
Digital Man wrote to All <=-
What do you guys think about potentially supporting "style codes" in message body text?
What do you guys think about potentially supporting "style codes"
in message body text?
I got the idea from reading about GoldEd+'s ability to
(optionally) highlight message text that has been marked-up (e.g.
this would *bold*, /italic/, etc.). GoldEd+ doesn't actually
supports bold, italic, etc., so it just uses different foreground
colors to indicate those text styles.
Interesting idea. Seems to me new changes like this can lead to text
potentially looking a bit ugly in clients & readers that don't support
those new things, so that's probably something to consider too. I
imagine SyncTerm would be updated to support it, but other terminal
programs & offline message readers, etc. might not know how to deal
with it.
I think the idea is that the text would still look /fine/ (and very readable) when viewed in a non-supporting viewer. I wasn't thinking SyncTERM would change necessarily, unless Deuce had plans for text styles. Could be cool though even without any special terminal support.
On 10-15-20 17:14, Digital Man wrote to All <=-
What do you guys think about potentially supporting "style codes" in message body text?
Hmm, if there's an option to strip them in QWK packets, then I'm fine with it. I don't want to have to hit "V" for every message and then be quoting ANSI escape sequences every message, or having a pile of raw control codes in messages. :)
So yeah it depends how it's implemented, and provided it doesn't create issues for any software outside of the BBS, why not? Might need another QWK option to strip formatting codes (like there is to strip CTRL-A codes).
I got the idea from reading about GoldEd+'s ability to (optionally) highlight message text that has been marked-up (e.g. this would *bold*, /italic/, etc.). GoldEd+ doesn't actually supports bold, italic, etc., so it just uses different foreground colors to indicate those text styles. But its possible some terminals do support those text attributes and other methods of message rendering (e.g. via HTML/CSS) could definitely support those text attributes.
Yeah worth considering, as long as it doesn't break anything. I bigger issue might be FTN - you'd have to strip the codes for non Synchronet systems, then Synchronet systems further downstream would miss out on the formatting. Probably could make it work on DOVE without too many issues, since we're mostly Synchronet there.
Rob,
I'm still having problems with the glitch in SyncTerm. The
version is still 1.1 from ftp://vert.synchro.net -- and I've
even downloaded versions from sourceforge and elsewhere.
You had noted a "bug" with the display, when it should be
80x24, the program only offers 80x25 or custom.
I've even
tried the font size at 8x14 or 8x16, and it still doesn't
show the ANSI right.
If there is a "fixed version", I haven't found it. I prefer
using SyncTerm, but I can't get around this glitch with the
telnet logon, and I think using another mode (i.e. SSH), would
still have the same ANSI issues.
Digital Man wrote to All <=-
What do you guys think about potentially supporting "style codes" in message body text?
I'd like to see that. I'm thinking about some web markup schemes
that people use to emphasize plain text, like *bold* text would look
like ASCII to everyone else, but Synchronet could render as bold.
Maybe /italic/ ?
You'd need a scheme to to escape literal characters, like in a URL,
though...
Re: Style codes in messages
By: Digital Man to Nightfox on Fri Oct 16 2020 12:47 am
What do you guys think about potentially supporting "style codes" DM>> in message body text?
I got the idea from reading about GoldEd+'s ability to
(optionally) highlight message text that has been marked-up (e.g. DM>> this would *bold*, /italic/, etc.). GoldEd+ doesn't actually
supports bold, italic, etc., so it just uses different foreground DM>> colors to indicate those text styles.
Interesting idea. Seems to me new changes like this can lead to text
potentially looking a bit ugly in clients & readers that don't support
those new things, so that's probably something to consider too. I
imagine SyncTerm would be updated to support it, but other terminal
programs & offline message readers, etc. might not know how to deal
with it.
I think the idea is that the text would still look /fine/ (and very readable) when viewed in a non-supporting viewer. I wasn't thinking SyncTERM would change necessarily, unless Deuce had plans for text styles. Could be cool though even without any special terminal support.
Were you thinking of using special characters around text (like the slashes you used around "fine") to mean certain kinds of markup? That would look okay even in terminals that don't support the special styling. It would be cool to see.
I'd like to see that. I'm thinking about some web markup schemes
that people use to emphasize plain text, like *bold* text would look
like ASCII to everyone else, but Synchronet could render as bold.
Maybe /italic/ ?
You'd need a scheme to to escape literal characters, like in a URL, though...
Time for a WYSIWYG version of Slyedit? :)
What ANSI issues? Perhaps if you described the problem I could either
get it fixed or help you to understand how to use the program better so the problem didn't occur. But right now, I really have no clue what problem you're trying to describe.
Rob,
What ANSI issues? Perhaps if you described the problem I could either get it fixed or help you to understand how to use the program better so the problem didn't occur. But right now, I really have no clue what problem you're trying to describe.
The resolution with Synchronet thinks it's 80x24, but SyncTerm
thinks it's 80x25.
On 10-16-20 09:47, Digital Man wrote to Tony Langdon <=-
There wouldn't be any ANSI or control codes in the messages. The markup syntax would use just *plain* US-ASCII characters, like that.
I don't think there'd be any reason to do anything special for QWK (no
new options needed). The only options needed would be for *viewing* messages and whether or not to recognize teh style codes and how to
treat them.
It appears GoldEd+ has supported these codes for years and people use
them without any special treatment (e.g. stripping) for networks. I use them (well *bold*) just out of habit.
On 10-16-20 07:17, poindexter FORTRAN wrote to Digital Man <=-
Digital Man wrote to All <=-
What do you guys think about potentially supporting "style codes" in message body text?
I'd like to see that. I'm thinking about some web markup schemes
that people use to emphasize plain text, like *bold* text would look
like ASCII to everyone else, but Synchronet could render as bold.
Maybe /italic/ ?
You'd need a scheme to to escape literal characters, like in a URL,
though...
On 10-16-20 11:29, Digital Man wrote to poindexter FORTRAN <=-
Right. Those are included in the ones that GoldEd+ supports. Also _underlined_ and #inverse#.
You'd need a scheme to to escape literal characters, like in a URL,
though...
Yeah, I don't know if there's a perfect solution, but usually any non-alpha char will short-circuit the mark-up parsing so *these words* would not be bold. Or maybe just *these, words* would not be bold. I haven't thoroughly analyzed the common or best parsing rules yet.
On 10-16-20 11:29, Digital Man wrote to poindexter FORTRAN <=-
Right. Those are included in the ones that GoldEd+ supports. Also _underlined_ and #inverse#.
Good point. Seems we're settling on *bold* /italics/ _underline_ and #inverse# so far. :)
You'd need a scheme to to escape literal characters, like in a URL,
though...
Yeah, I don't know if there's a perfect solution, but usually any non-alpha char will short-circuit the mark-up parsing so *these words* would not be bold. Or maybe just *these, words* would not be bold. I haven't thoroughly analyzed the common or best parsing rules yet.
Opening a can of worms there. ;)
I thought I already explained that bug. Either set "Hide Status Line"
to "Yes" in SyncTERM or connect using RLogin or SSH instead of Telnet. It's a fixed bug, but there's no recent Windows build that includes the fix.
Also, Black Panther said he was not able to connect to tbolt.synchro.net but the BBS was up. Is the DYNDNS forwarding messed up?? I have it enabled over here.
On 10-17-20 01:45, Digital Man wrote to Tony Langdon <=-
Those are the styles supported by GoldEd at least. You can read about
its "stylecodes" here: https://github.com/golded-plus/golded-plus/blob/master/manuals/gold_ref. txt
Opening a can of worms there. ;)
Everything is. :-)
Rob,
I'm still having problems with the glitch in SyncTerm. The
version is still 1.1 from ftp://vert.synchro.net -- and I've
even downloaded versions from sourceforge and elsewhere.
You had noted a "bug" with the display, when it should be
80x24, the program only offers 80x25 or custom. I've even
tried the font size at 8x14 or 8x16, and it still doesn't
show the ANSI right.
If there is a "fixed version", I haven't found it. I prefer
using SyncTerm, but I can't get around this glitch with the
telnet logon, and I think using another mode (i.e. SSH), would
still have the same ANSI issues.
But things like *bold* and _italics_ are common interpretations for many message viewers.
You'd need a scheme to to escape literal characters, like in a URL,
though...
Yeah, escapes would be helpful for those cases, where a literal string is needed.
On 10-18-20 16:21, Tracker1 wrote to Tony Langdon <=-
On 10/16/2020 10:41 PM, Tony Langdon wrote:
But things like *bold* and _italics_ are common interpretations for many message viewers.
In Thunderbird it's *bold* /italic/ and _underlined_
On 10-18-20 16:24, Tracker1 wrote to Tony Langdon <=-
On 10/16/2020 11:08 PM, Tony Langdon wrote:
You'd need a scheme to to escape literal characters, like in a URL,
though...
Yeah, escapes would be helpful for those cases, where a literal string is needed.
Thunderbird both keeps the characters *and* changes the display, so the characters are still there, but just in bold with the in-between text.
What do you guys think about potentially supporting "style codes" in message body text?
On 10/16/2020 11:08 PM, Tony Langdon wrote:
You'd need a scheme to to escape literal characters, like in a URL,
though...
Yeah, escapes would be helpful for those cases, where a literal string is needed.
Thunderbird both keeps the characters *and* changes the display, so the characters are still there, but just in bold with the in-between text.
Re: Re: Style codes in messages
By: Tracker1 to Tony Langdon on Sun Oct 18 2020 04:24 pm
On 10/16/2020 11:08 PM, Tony Langdon wrote:
You'd need a scheme to to escape literal characters, like in a URL,
though...
Yeah, escapes would be helpful for those cases, where a literal string is needed.
Thunderbird both keeps the characters *and* changes the display, so the characters are still there, but just in bold with the in-between text.
That seems to contradict this Thunderbird documentation: http://kb.mozillazine.org/Plain_text_e-mail_%28Thunderbird%29
In Thunderbird it's *bold* /italic/ and _underlined_
That looks the same as GoldEd. :) Some of the social media and chat clients use _italics_ for some reason. Discord really screws this up, doing *italics*
as well as _italics_, and ignoring //.
Thunderbird both keeps the characters *and* changes the display, so the
characters are still there, but just in bold with the in-between text.
That seems to contradict this Thunderbird documentation: http://kb.mozillazine.org/Plain_text_e-mail_%28Thunderbird%29
I don't have Thunderbird installed to try it myself. I wonder if maybe there's another option to strip the markup characters too.
On 10/19/2020 7:35 PM, Digital Man wrote:
Thunderbird both keeps the characters *and* changes the display, so the >> characters are still there, but just in bold with the in-between text.
That seems to contradict this Thunderbird documentation: http://kb.mozillazine.org/Plain_text_e-mail_%28Thunderbird%29
I don't have Thunderbird installed to try it myself. I wonder if maybe there's another option to strip the markup characters too.
https://i.imgur.com/vFKKt9g.png
Note: it also delimits on a signature tear of "-- " on an otherwise
blank line... would be cool if this was auto-added as trim(message) + "\n\n-- \n" as a signature prefix when appending user signatures.
On 10-19-20 20:07, Tracker1 wrote to Tony Langdon <=-
Markdown is usually *italics* and **bold** so that may have something
to do with those influences.
In fact MS Teams and other apps will often catch common markdown or
emoji escapes :+1: or :thumbsup: ... there's some variance there.
For UTF8 users, could probably catch emoji sequences and replace with
the emoji character (counting on double-wide use in the display). I
use the Fira Code font for my terminal and Rocket.rs for my prompt, so
the extra characters are pretty useful to me.
80x24 is when you use 80x25 with the status bar.
Re: Re: Style codes in messages
By: Tracker1 to Tony Langdon on Sun Oct 18 2020 04:24 pm
On 10/16/2020 11:08 PM, Tony Langdon wrote:
You'd need a scheme to to escape literal characters, like in a
That seems to contradict this Thunderbird documentation: http://kb.mozillazine.org/Plain_text_e-mail_%28Thunderbird%29
I don't have Thunderbird installed to try it myself. I wonder if maybe there's another option to strip the markup characters too.
Greetings Digital!
Monday October 19 2020 19:35, you wrote to Tracker1 about an urgent matter!:
Re: Re: Style codes in messages
By: Tracker1 to Tony Langdon on Sun Oct 18 2020 04:24 pm
On 10/16/2020 11:08 PM, Tony Langdon wrote:
You'd need a scheme to to escape literal characters, like in a
That seems to contradict this Thunderbird documentation: http://kb.mozillazine.org/Plain_text_e-mail_%28Thunderbird%29
I don't have Thunderbird installed to try it myself. I wonder if maybe there's another option to strip the markup characters too.
I am not sure if this was mentioned or not but in golded I just used STYLECODES hide
https://i.imgur.com/vFKKt9g.png
That's kind of a bummer. Does it support /*mixing*/ styles? Or *multiple words*?
Note: it also delimits on a signature tear of "-- " on an otherwise
blank line... would be cool if this was auto-added as trim(message) +
"\n\n-- \n" as a signature prefix when appending user signatures.
Does *any* other program treat "-- " special? What does Thunderbird refer to that line as?
Note: it also delimits on a signature tear of "-- " on an otherwise
blank line... would be cool if this was auto-added as trim(message) +
"\n\n-- \n" as a signature prefix when appending user signatures.
Does *any* other program treat "-- " special? What does Thunderbird refer to that line as?
On 10/19/2020 8:59 PM, Digital Man wrote:
Note: it also delimits on a signature tear of "-- " on an otherwise
blank line... would be cool if this was auto-added as trim(message) +
"\n\n-- \n" as a signature prefix when appending user signatures.
Does *any* other program treat "-- " special? What does Thunderbird refer to that line as?
In addition to my prior reply... several nntp and email programs do recognize this and may have settings to exclude signatures from replies.
https://en.wikipedia.org/wiki/Signature_block#Standard_delimiter
Seems like a good idea to me.
I'd vote for Markdown, or a subset of Markdown. It's been around for 16 years (see https://daringfireball.net/projects/markdown/syntax), and has become a de-facto standard on tons of popular tech sites. GitHub, StackOverflow, Reddit
are among those who use it, or a modified version of it.
To me, it's a good fit for BBSes. It was designed to look good and be very readable, even in plain text when it's not interpreted.
Some of the rules would work well in a terminal, others (hyperlinks, inline images, etc) probably only make sense in the web interface.
| Sysop: | KrAAB |
|---|---|
| Location: | Donna, TX |
| Users: | 2 |
| Nodes: | 20 (0 / 20) |
| Uptime: | 112:38:48 |
| Calls: | 248 |
| Files: | 526 |
| Messages: | 34,365 |
