1.8.3 ANSI Change Summary

Submitted by walker on Sat, 2007-01-27 07:21

This release, 1.8.3p0, marks a complete change in how PennMUSH handles ANSI
and Pueblo internally. This will impact distributions with hardcode changes
that use ANSI in the hardcode, and a few changes in softcode.

Major changes:

* The database is altered very slightly - Attributes that are seen to have
pueblo or ANSI codes are processed and written out in the new format that
Penn uses internally. This will only impact attributes that have embedded
ansi or pueblo. If you back out the upgrade to 1.8.2 or earlier, those
attributes will be considered to have (broken) pueblo markup, and no ANSI.

* The ANSI_* #defines no longer have 'raw' ansi codes in them. Instead, they
use the internal markup format, and should ideally each be closed with
ANSI_END. In other words:
'ANSI_RED ANSI_HILITE "Foo" ANSI_NORMAL' now becomes
'ANSI_RED ANSI_HILITE "Foo" ANSI_END ANSI_END' or it can be
'ANSI_HIRED "Foo" ANSI_END'.
ANSI_NORMAL is #define'd to ANSI_ENDALL, to preserve backwards compatability.

* There is currently no way (that we know of) to get a standalone ansi
opening tag. That is, you can't use [before(ansi(r,x),x)]... to make
the entire line red. Attributes that currently had this standalone ansi
tag in them will now not work in that function. In other words, attributes
will be modified to include closing tags for all their opening ansi.

What does all this get you?

* MUCH more 'ansi-aware' functions. regmatch(f[ansi(r,o)]o,...,0) %q0 gets you
a "foo" with a red first 'o' instead of the f, an escape character, and a [.

* Properly nesting ansi. If you used:
setq(0,ansi(r,bar)) [ansi(c,foo %q0 baz)],
You would get a cyan 'foo', a red 'bar' and a plain 'baz'. Now, both 'foo'
and 'baz' are properly cyan.

* decompose() now works with ANSI *and* Pueblo. And as a bonus, it will
optimize the output, so if you have [ansi(r,f)][ansi(r,o)][ansi(r,o)], put
through decompose(), it will print [ansi(r,foo)]

* Less buffer usage. If you find yourself hitting buffer limits because of
too much ansi, you'll find you can now pack just a wee bit more text in
there.

* The 'd' and 'D' "colors" for ANSI - These force the client to use its
default colors for the foreground and background, respectively.

* ansi_normal is an alias for ansi(dDIHFU,...) making what's inside it
explicitly normal.

Downsides/issues:

* This is a "dot-zero" release - While these changes have been tested
rather extensively on M*U*S*H for quite some time now, you may run
into issues we haven't found.

* Using regedit*() with strings that have markup is now quite slow. That's
the price of 'ANSI-perfect regedit'. Regedits that don't deal with ansi
will still be quite fast, though.