I’ve hacked it, just setting that to true during my plugin’s function, and setting it back to whatever it was after. Still not sure why this is there.

And it actually affects getting values–not the generation of them. So I can’t just hack it for the createPerchanceTree call, but up to the point it’s completely processed and never going to be used again, basically.

__evaluateText is an engine-internal thing, and your code could break if you rely on that. In general, in JS, you should only use variables/functions that begin with _ if you were the one that made it. But it’s my bad because I can’t expect people to know that, and it’s my bad for leaving it accessible - I need to tidy up all those globals. I’ll add a warning for generators that use it, and now that I know people could be using stuff like this, I’ll make sure to keep these functions around as much as I possibly can (seems possible for __evaluateText, but there are other internal functions that may be much harder to keep).

So what I’m gathering from the various comments in this thread is that there are two thing to report:

• Feature request: You want something like evaluateItem (which can be called on strings like "{1-2}".evaluateItem), except it should allow passing in a “root”? So like "[b]".evaluateWith(newRoot) where newRoot was created with createPerchanceTree? So b gets pulled from newRoot. This seems like a fair request. How important is it for you to also be able to choose the this reference? E.g. do you need/want "[b]".evaluateWith(newRoot, parent)?
• Bug report: If you have foo = \n, and you write [console.log(foo)] then it logs the literal characters \ and n whereas if you write <script>console.log(foo)</script> then it logs a newline character. Example: https://perchance.org/9tffz7swhn#edit I think I actually designed it like this on purpose so that you don’t have to add extra backslashes before characters depending on how “deeply” you’ve referenced it:

output
  output: [depth1]

depth1
  depth1: [depth2]

depth2
  depth2: \\n

https://perchance.org/0u6l500kua#edit

If I fixed this “bug” then it would output a newline instead of the literal \n characters. With the current code, no escape-character-stripping is done in square block evaluation - it’s instead done when the square block’s output actually gets placed into the HTML. I.e. processing escaped characters is only done right at the end. This means that if you refactor your code and the depth of “references” to various items changes, then you don’t have to go through and add/remove backslashes.

But I agree that the inconsistency of behavior here RE script tags is very strange. This seems big enough that it may have to wait for v2 of the engine though - I’m struggling to think of a way to fix this without causing some generators to break. If you have any thoughts here, please let me know, and thanks for your in-depth exploration here! It’s very helpful. I’ll link this comment from the perchance.org/known-bugs page.