Erm, I've tried searching the Quest Docs on this, but can't find anything.
Perhaps someone has come across this before, perhaps it's on Alex's list even.

When displaying text in Quest, there are symbols it can't display (less than, greater than) - which can be accessed via "$symbol(lt)$" or "$symbol(gt)$" respectively ..

When you want a hash or percentage sign, you double it up:
## prints out "#", %% prints out "%".

Now what about the "Pipe" character ?
| is used for text formatting (bold, italic, etc) - but if you want to print out (verbatim):
"[ Y | N ]"

How do you (without using a text block - which has just sprung to mind as a possibility although I'm not sure) print out a pipe character?

I don't think you can print a pipe character using a text block, either, since you can now use text formatting codes in them.

Beyond that, I have no idea.

I hope Alex revises this formatting and simplifies it down neatly.
| could be treated as an escape character (or better yet, \ could), and the character after that used for determining what is to be produced.
So instead of "##" "\#" would be used.

I can't quite see how HTML-style formatting will fit in, especially seeing as how < and > can't be used inside a text string (with the "escape character" idea, you'd use \G \S - "greater than, smaller than" - or something like that).

Just seems bizarre that we have 3 different methods for processing a character for output (function, ## and %% or |cb)

There's 52 letters in the English alphabet, 120-something plus using ascii.
I'm sure we can assign sane meanings to all of them for this purpose (and yes, it does strike close to your colour idea Overcat).

...assign sane meanings to all of them for this purpose...

Especially if the scripter can assign them him/herself. (Unless that's what you meant.) It's one thing to have them hard-coded, and another to have them mutable. Perhaps they could have default assignments but could be overwritten by the scripter.

.. They should definitely NOT be able to be changed by the coder..

What would be the purpose of switching \r with \g ?
You wouldn't be adding functionality at all - you'd be over complicating the Quest player, and causing the text formatting to become unreadable without you knowing exactly how it's switched.

The whole reason for formatting codes is that there's one standard way to do so (look at the echo command, or C output codes, perl, python etc)so that everyone can read and write the SAME thing.

NOTE: I am not against "operators" being overridden (ie : std::cout << "hello" << std::endl ) since they simplify code and also add a more graphical flow of the code.
Allowing a user to "switch" around \[x] codes would not provide anything similar.

The whole reason for formatting codes is that there's one standard way to do so (look at the echo command, or C output codes, perl, python etc)so that everyone can read and write the SAME thing.

I see what you're saying. I wasn't thinking clearly! . The user shouldn't override the set codes themselves - rather, they should be able to define in-line codes of their own.

This would be cool:

set color <c1; 100909>
set color <c2; FF0909>
set formatter <f1; |c1|b>
set formatter <f2; |c1|xb>

...

msg <|f2Joe:  |f1Hello.>

Yes, you're talking about "styles" there .

So, I'd prefer:

style <name1; \f\h\*[a1a1a1] >
style <name2; \f\h\*[b2b2b2]>

.. the f and h formatting do something (like default font and highlights the text - or something to be defined) and the \*[] changes the colour (RGB hex).

You'd then use this in your text:

msg <default \s[name1]style is now name1 \s[name2]style has changed again!\B This is in bold\b - and this isn't.>

Doing it that way has potential ambiguity problems.

Which part would be ambiguous?
If you mean there's already a "style" type, then I really just used it to show my POV - not for any real-case use.

hmmm, oh a thought just popped into my head - you can already do this... using strings!
.. so if you set a string like so:

set string <default; |cb|xb|xi|xu|s0>
set string <style1; |cr|s2|b>

You can use them in your output to format it the way you'd like (so no need for styles).

hmmm, oh a thought just popped into my head - you can already do this... using strings!

Nice!