Italics and bold end at newline?

[benhamill]

If you write:

[i]This is a reasonably long sentence that has a few clauses
to it.[/i] And this is shorter.

It will render as:

this is a reasonably long sentence that has a few clauses to it. And this is shorter.

I haven't dug into the source to figure out what's doing the tag parsing and why it might be working this way, but would y'all accept a PR to make it render more intuitively (assuming I can figure it out)?

[CareyJWilliams]

This happens because the CS interpreter works through your code line by line, running each code statement or printing each text line in turn (proper, carriage return lines that is - it's fine to use a text-editor that wraps).
Thus when you break your tags up onto two lines, it will parse the 1st line: "[i]This is a reasonably long sentence that has a few clauses", and then the second line: "to it.[/i] And this is shorter.".

The [i] brackets are replaced with HTML "" tags and most modern browsers will attempt to automatically add any closing tags you miss (so that first part still works).
The second line will just ignore the stray "" though.

The only way around this would probably be to immediately recollect all the printed text after a page render and reparse it as one chunk, replace the result and restore it to the screen.
Long story short, I don't think this is a quick and easy fix.

I'd sooner suggest just using two pairs:
[i]This is a reasonably long sentence that has a few clauses[/i]
[i]to it.[/i] And this is shorter.

You could also store the value in a variable and use a tag line break, as that would all get parsed and printed together. For e.g. the following would work:

*temp temp "[i]First Line[n/]Second Line[/i]"
${temp}

[benhamill]

Those suggestions are all fine for shorter examples. In my case, I am using italics to indicate that a section is a flashback (which is pretty common). Having a [i] at the start or every line looks gross and makes it hard to edit.

It might pay to look at how a few markdown parsers do paragraphing, since it's similar in syntax. My initial suggestion was going to be to do two passes, basically: Identify commands and paragraphs, then run things through a formatting step.

It's weirdly inconsistent, to me, that paragraphs join adjacent lines and get wrapped in <p> tags, but <i> and <b> don't behave the same way. 🤷

Having Markdown in some many places has really, really spoiled me, I have to say.

[CareyJWilliams]

Agreed, it does look nasty but markdown parsers have the advantage of not needing to run code statements intermittently. Making it re-parse the text after statements (baring in mind that a statement can be cause for extra text to be printed), is pretty much what I'd suggested though.
It's just that it would - looking at the code - require quite a bit of restructuring to do that, and it's down to COG/Dan to decide whether or not it's worth their time to change it.

[benhamill]

Oh sure. It always had to come down to @dfabulich making the call, regardless of the level of effort involved. I'm willing to put in some time trying to figure out a good restructure, but, of course, CoG would then have to maintain it, so... 🤷

[dfabulich]

I think the closest I'd get to fixing this bug is to at some point rewrite the UI into React or some other web framework that includes a virtual DOM, so I can rely on the library to do the "second pass" instead of keeping a buffer in memory and handling it myself.

FWIW, we, ah, don't add <p> breaks. We add double <br>s. So non-semantic. Very sad.