Idea: categorize messages (including in-server) with prefix coding

[wyld-sw]

Some MUCKs use muf words and mpi macros to visually separate messages to help identify success, failure, or unknown. I've seen this called "stoplights" as they're usually accompanied by a red/yellow/green color.

This seems to be used well on HLM, and having it built-in for server messages might be good too, in addition to the following MUF primitives and MPI functions:

• PREFIX_GOOD or {prefixgood:} could change a string "Your command was successful" into something like "<*> Your command was successful.", with a system-defined prefix that may include color codes.
• PREFIX_WARN or {prefixwarn:} could change a string "Please review the above messages." into something like "<?> Please review the above messages.", with a system-defined prefix that may include color codes.
• PREFIX_BAD or {prefixbad:} could change a string "Permission denied." something like "<!> Permission denied.", with a system-defined prefix that may include color codes.

Sysparms that could work with this include:

• enable_message_categories. if no, none of these new words or macros [or server functionality] change the message.
• message_category_good_prefix. Prepended to the message if the "good" category is used. Can include color codes.
• message_category_bad_prefix. Prepended to the message if the "bad" category is used. Can include color codes.
• message_category_warn_prefix. Prepended to the message if the "warn" category is used. Can include color codes.

If color codes are accepted, we would need to add a reset code in case the prefix doesn't include it.

(names of sysparms, primitives, and functions not set in stone, of course!)

Thoughts?

[tanabi]

I see the utility here. These could be implemented as 'internal defines' for the MUF ones as really each one of these calls is just some strcat's and swap's.

I don't really see a need to make @tune parameters as that kind of neuters the point. It would be trivial for a MUCK to override the system defaults with their own defines if they wanted, or maybe msgmacs overrides for MPI (not sure if msgmacs can override an MPI macro, I've never tried ...)

Can always add the tunes later if there's a request from an operator for that, as well. Just keep it simple to begin with since this is kind of an experimental feature -- you know, we'd be adding this and seeing if anyone wants to use it rather than something a user has requested.

[wyld-sw]

Ok, makes sense about starting off with no @tunes.

HLM uses:

• [%] (green) for "good"
• [?] (yellow) for "warn"
• ]![ (red, note reversed brackets) for "bad"

Are these good, or should we come up with our own? If these look good, I may pop into HLM to discuss our intentions.

[tanabi]

Those are fine. The 'good' one is a little weird to me but I don't have a better idea :)