[Feature] More Markdown/HTML features in chat

[Xetem]

I thought I remember @Accipiter saying the markdown in chat is parsed manually out of a message with regex (Though I may be misremembering), so this may be a bit to implement. But there are a couple text ornaments that I think would help some transition over from other services (namely F-Chat) and to help spice up conversations.

• Superscript and Subscript tags, either through html tags (<sup> and <sub>), or custom markdown flavoring (I’ve seen some use ^this^ for superscripts but I’m pretty sure markdown doesn’t have a tag for either in the base language.)
  I along with other F-Chat users (who have the bbcode equivalent there) often use superscripts for reasons like ^{high talking} and subscripts for reasons like _whispering. But I’m sure others can find many reasons for it. It would also be nice if they could be chained for fun, but I don’t know how feasible that would be. (Though it seems possible in html, Woo^ooo_ooo_ooo^ooo^ooo and can go 3 levels deep, but that’s definitely not necessary if it’s not already rendered through native html…)
• an accessible way to type non-standard characters. I’m thinking through html escape codes (e.g. æ would get you æ). If I ever want to use those characters on a keyboard without a numpad I’ve got to go hunt them down (I have characters with non-standard Latin characters in their name). I would imagine it would just be capturing the escape code and passing it to the client html renderer without escaping the & or ; (and that may also be the case for tags like the above).
• Text colors are fun. Using something like <color=red> or similar to get red text (it looks like the traditional html tags are being interpreted on the forum, but not being rendered . Again, it’s just something fun to add to spice up conversation.

[Accipiter]

Completely true; the client just uses regex find and replace. If we with to do a more complicated tag system (like bbcode or HTML tag parsing), it would need to be rewritten. But I prefer to stay to simpler formatting for now. So let’s see…

Superscript & subscript

Superscripts and Subscripts is a nice idea! They are non-intrusive enough for me to like it
After some in-game discussions with Lewd, we came to the conclusion that ++ and - - might work well for them:

++superscript++
--subscript--

And if one would wish to add multiple levels, adding more +/- could be achieved. But for starters, let’s try a single level.

Non-standard characters

HTML escape codes could work. But, that is rather techy. Maybe a way to define your own “replacement” alias, where you can trigger replacement?

For example, if we have: ae => æ
That means, you could type ae, and then press perhaps CTRL + Space (or some other trigger) to replace it.

This can be used for other replacements as well:

woo => WOOooo--ooo--ooOOoo--oo--

Color tags

It has been suggested before, but I still think it may get too intrusive in RP. But I am open to be convinced otherwise

[Xetem]

Gotcha, so simpler is better. _{I won’t mention parsing html with regex, that meme’s apparently dead.}

Superscript & subscript

I like ++ and --, it seems intuitive to me (and hopefully others) and wouldn’t be obtrusive to normal conversation (unless someone’s talking about C++ ) and single level is perfectly fine. I just know that it can be done in html so if we found a way to regex it in no fiddling needed.

Non-standard characters

I like the idea of triggers for shortcuts. I just threw out using html escape character because that’s what I know is standard in markdown-ish places. And I love the idea of extending it to any replacement shortcuts, it could make.

Color tags

We talked about this in-game, I more threw it out there because I know it’s a thing. And I completely agree with a desire to have it not clutter a mostly IC setting. I know I’ve used it semi-productively on other RP servers, but in a way that could easily be accomplished other ways.

[Accipiter]

The only “issue” I have with the ++/-- idea is how well you can make your WOo_OooooOoO^oOOoo thingy. I mean, how to do multiple formatting following eachother?

Woo--Oo-- ---oo--- --oO--oO++oO++ +++oo+++ ++Oo++o

THe issue there is the spaces between a single-level and a double-level sub/sup, where you probably need to space-separate them. But you can probably solve that with a zero-width space (unless I strip them away already).
Maybe just too much of a corner case scenario for me to worry too much about it

[Xetem]

Yea that’s a tough one, I think zero-width spaces would work to keep the control characters apart if they’re not being cleansed out of the string. But it is a fairly far corner case.

As an aside but related though, how are asterisk-activated bolds and italics handled in this regard? It seems to be the same issue. Like if I were to type *some italic text***some bold text** would I properly get

some italic textsome bold text

Because if that worked then I think it may be a non-issue. as butting up a closing ++ with an opening +++ would sort itself out. The resulting display html would just be a bit messy. Some++superscript+++++supersuperscript++ would look like

Some^{superscriptsupersuperscript}

but be formatted in html as Some<sup>superscript</sup><sup><sup>supersuperscript</sup></sup>. But that may be inconsequential.

Just checked in-game. Italics aren’t available in asterisk-flavor, but it parsed the bold correctly out of it.

[maximus]

Italics are available in game , through the use of underscores.
I don’t think a complete aversion to markdown using [] tags is necessary, especially for niche items like super/subscript. Ensuring that parsing those tags as pure regex without delimiters doesn’t start messing with other natural input is going to be a knife edge walk. I’d rather [sup]woo[sup]ooo[/sup][/sup] for reliability.

As for non-native characters, supporting the entire HTML tagset would be a bit of a hassle, no? For those who are trying to refer to said characters, figuring out the tag needed would be even more of a hassle. I’d say the onus for providing said character input would more appropriately be client-side, with alt codes or on-screen keyboard, rather than some elaborate ‘please all’ mechanism implemented in the system itself.

Though this did remind me to do a quick test - and @Accipiter - you may want to throw in some anti-Zalgo in the parser.

[Accipiter]

About the superscript/subscript part; I just made a release with ++/-- . Let’s see if it works.
But yeah, reliability is nice. Simplicity is nice too.

And I hope we won’t have too many C++ discussions for it to cause too much problem.

And regarding anti-Zalgo?
I think the easiest thing to do would be to not let a chat log event overflow into another chat log event, by putting overflow: hidden on the container.
I would need to do some extra work as tags like ooc is already overflowing the container, and would be cropped. But it would at least solve Zalgo in the chat log.

But then we have descriptions, mail, etc. Text in other places. Ouff…