UNDO clears screen if color enabled

[DavidGriffith]

If a game has declared "Constant COLOUR;", then the screen will be cleared after an UNDO command is issued and before the UNDO is executed. This doesn't happen if color mode is not used. I'm not sure why this was done. Maybe something about undoing something that changed colors?

[DavidGriffith]

Constant Story "UNDO AND COLOR";
Constant Headline "^An Interactive Bug Reproduction^";

Constant COLOUR;

Include "parser.h";
Include "verblib.h";

Class Sphere
    with name 'sphere' 'spheres/p' 'ball' 'balls/p' 'crystal' 'crystals/p',
    before [x;
    Search:
        x = self.color;
        @set_colour x 1;
        "Your vision swirls disconcertingly.  In a few seconds, 
        you're fine, but things have changed.";
    ];

Object Start_Room "Somewhere"
    with description "You're not sure where you are.",
    has light;

Sphere -> Sphere_Red "red sphere"
    with name 'red',
    description "This crystal sphere is colored bright red.",
    color 3;

Sphere -> Sphere_Green "green sphere"
    with name 'green',
    description "This crystal sphere is colored bright green.",
    color 4;

Sphere -> Sphere_Blue "blue sphere"
    with name 'blue',
    description "This crystal sphere is colored bright blue.",
    color 6;

Sphere -> Sphere_White "white sphere"
    with name 'white',
    description "This crystal sphere is stark white.",
    color 1;

[ Initialise;
    clr_on = true;
    location = Start_Room;
    "Time for squashing bugs!";
];

Include "grammar.h";

[DavidGriffith]

http://inform7.com/mantis/view.php?id=1755

[DavidGriffith]

The screen-clearing happens in RestoreColours() in parserm.h

[DavidGriffith]

There appears to be no logical reason to do this screen-clearing. Both with and without the ClearScreen() call, the current colors are reset to the defaults when an UNDO is processed. With the ClearScreen() call disabled, earlier color changes remain intact:

UNDO AND COLOR
An Interactive Bug Reproduction
Release 1 / Serial number 160424 / Inform v6.33 Library v6.12.1 S
...
>LOOK INTO RED SPHERE
[text is subsequently red, as is the status line]
Your vision swirls disconcertingly.  In a few seconds, you're fine, but things
have changed.

>LOOK INTO GREEN SPHERE
[text is subsequently green, as is the status line]
Your vision swirls disconcertingly.  In a few seconds, you're fine, but things
have changed.

>LOOK INTO BLUE SPHERE
[text is subsequently blue, as is the status line]
Your vision swirls disconcertingly.  In a few seconds, you're fine, but things
have changed.

>UNDO
[text and status line are now white (default)]
Somewhere
[Previous turn undone.]

>

My question now is this: What advantage is gained by doing ClearScreen() when processing RestoreColours()?

[DavidGriffith]

This odd behavior is related to the fact that Glulx's style model is not entirely compatible with that of the Z-machine. One can give suggestions to the Glk layer about color, but you're not guaranteed to get it, monochrome mode notwithstanding.

This from @vlaviano:
So the main problems with glulx color are:

• Only 11 styles, most of which already mean something. Some of the lesser used ones can be repurposed to mean different text colors, but it's still too few.
• There's no guarantee that the glk library will honor style hints for text color (or anything else).

Therefore I'm going to leave this as-is until @erkyrath does something with the proposal for a Glulx style model. Discussions on this can be found http://www.intfiction.org/forum/viewtopic.php?f=7&t=15730&start=10#p78664 and http://www.intfiction.org/forum/viewtopic.php?f=7&t=19496