Or .escaped or .plain or whatever you want to call it.
Currently, because string is automatically evaluated, [code] and {options} are processed too. This is pretty annoying if that string is meant to be returned and put into the HTML as-is, not evaluated at all. So I have to find-replace [, ], {, and } characters to escape them all manually.
This could be done with a .raw property on strings, for example–to make it easier for creators to do this. (I’m guessing this would be a fairly common things people need to do, when working on non-trivial plugins, etc.)
It’s a good request. I agree that the current situation isn’t ideal. I’d have to dive into old code to see whether this is hard or easy to implement (i.e. whether ‘raw’/original string is already “threaded through” to where it’s needed for this to be implemented easily). Something similar to your question here also happens to be mentioned on perchance.org/known-bugs and the workaround that I mention there (and regularly use myself) is to just use functions whenever I want to be sure I’m working with ‘raw’ stuff i.e. this:
foo() => return "hi {1|2|3}"instead of:
foo = ["hi {1|2|3}"]for example.
Thing is, I was returning a string from a function in the first place. But to a
[code block]in HTML. Maybe that was the issue? In the end I just used a function that took the string and escaped the special characters, and returned that. So, should be possible with a simple getter that does that maybe?Oh right, yes, square blocks will always evaluate the text before returning it, so a string.raw type thing wouldn’t help with this IIUC. Here’s a tested/robust plugin for escaping in case it’s helpful: perchance.org/literal-plugin
Okay I don’t think I’m being clear here… Look at this test: https://perchance.org/test-return-string-or-plain-string-89987987#edit
Two functions are called from HTML code blocks. One returns a string with special characters and it is evaluated and those characters are no longer shown. The other returns the same string, but with special characters escaped by a
plain_text()function beforehand. Because the special characters are escaped, they are not parsed by the engine and show as normal regular text, just with those escaping slashes removed.So you can use that kind of function to spit out untouched HTML. And such a function could be built-in to the engine fairly easily.
And such a function could be built-in to the engine fairly easily.
Yep, something like perchance.org/literal-plugin could definitely be built in - it’s a fair request. I thought you were asking for something different (i.e. stop the actual evaluation at some point in the engine vs just escaping it), though I’m not sure if my original interpretation even makes sense, or wouldn’t just be equivalent to escaping right before output to HTML anyway.
Yeah skipping processing for a given string would be ideal, but I know it’s super deeply integrated into everything currently. Just the escaping getter is all 👍