More on the RestoreColours/ClearScreen issue.
Glulx authors are stuck having the screen cleared after SetColour regardless of our decision, so we can focus on zcode here.
If we remove the call to ClearScreen, an author who wants the screen cleared after restore/undo will need to do something like this:
Object RestoreUndoHook LibraryExtensions
with ext_messages [;
Restore: if (lm_n == 2) { ClearScreen(); print "^"; }
Miscellany: if (lm_n == 13) { ClearScreen(); print "^"; }
];
If we keep the call to ClearScreen, an author who doesn’t want the screen cleared after restore/undo will need to Replace RestoreColours. For a fair comparison, we can assume that the author knows he’s defining COLOUR and isn’t compiling to v6. That gives us:
Replace RestoreColours;
Include "Parser";
[ RestoreColours; ! L61007, L61113
gg_statuswin_cursize = -1; ! Force window split in StatusLineHeight()
if (clr_on) { ! check colour has been used
SetColour(clr_fg, clr_bg, 2); ! make sure both sets of variables are restored
SetColour(clr_fgstatus, clr_bgstatus, 1, true);
}
];
In the one case, the author needs to be familiar with the intricacies of LibraryMessages or ext_messages. In the other, the author needs to be aware of the private RestoreColours routine and how it interacts with SetColour and ClearScreen. I prefer the former, because it uses the library’s documented public API instead of requiring knowledge of library internals.
An author who wants consistent behavior between zcode and glulx is forced to clear the screen after SetColour. He can accomplish this by calling ClearScreen after each explicit call to SetColour for the benefit of the zcode version. (If we decide to remove the ClearScreen call, he’ll also have to use the ext_messages technique above.) These ClearScreen calls will be superfluous for glulx, but not harmful.
Another consideration is old code that’s recompiled against 6/12. If we remove the ClearScreen call, old games may see a change in behavior after restore/undo.
An open question is which screen-clearing preference is an author likely to have if he knows that both options are available. We’d want the library to support the most common preference by default and let others use one of the two techniques above to obtain the alternate behavior.
I spent some time researching the history of RestoreColours, looking for a rationale for the ClearScreen call. I wasn’t able to locate the change other than to place it between L61007, which introduced the precursor to RestoreColours, and L61113, which added the gg_statuswin_cursize assignment.