I wrote earlier:
> As distasteful as this 'port-with-print-state' concept may be, I'm not
> aware of a better solution. Fluids aren't quite right, because a
> structure printer might cause I/O to happen on another port.
Having thought more on this, I think fluids might be the right tool.
The only detail is, the print state would have to include a reference to
the associated port. Then, if the port passed to 'write' or 'display'
doesn't match the one associated with the current-print-state, it would
be saved and later restored, with a fresh new current-print-state used
for the duration of that 'write' or 'display' call.
What do you think?
Mark
