I'd like to see that too. But I say we already have it.
This is why I like the
<colorentry red 255 0 0>
Leaving aside the need to determine what commands don't need a balancing
</> command, I may just point out that this will defeat another of my
auto-correction schemes: if I am parsing a command name and I encounter
a whitespace character, I assume that the '>' was left out or truncated
in some fashion, and I insert it myself. This is in the interests of
minimising the number of characters that are skipped over to find a
matching '>' when something goes wrong. I could no longer make this
assumption with commands such as yours. Maybe my lexical analyser is
just a little too paranoid. :-)
The opposite could very well happen. It is arguable that any
SGML-ish parser should ignore commands it doesn't understand,
passing the text unmodified, in which case you could say that
<colorentry> red 255 0 0 </colorentry>
*must* be result in "red 255 0 0" being
displayed as part of the message.
This is the default behaviour for text/enriched at the moment, so we
don't have the SGML/HTML problem. It's also why we need a general command
like <param>, so we can wrap up "viewer directives" like so:
<param><colorentry> red 255 0 0 </colorentry></param>
Then, a parser that doesn't understand <colorentry> can say "I don't know
what this is, but I can safely drop it". Maybe my previous message wasn't
very clear, but this is what I was getting at.
Now, since there is only one mechanism to indicate where viewer directives
occur, we can invent a different syntax for <param> blocks if we like. To
extend my previous example, and using '()' instead of '{}':
<param>colorentry(red(255 0 0) blue(0 0 255))</param>
But, I am still unconvinced we should define such a syntax now, but rather
say that <param> is where it will happen and that we'll leave it until
experimentation suggests what syntax is best.
Cheers,
Rhys.