Re: Discussion for %display-auto-compilation-messages (and --no-auto-compilation-messages option)

[Mark H Weaver]

Mark H Weaver <address@hidden> writes:

> For example, I recently discovered that REPL Servers weren't redirecting
> the warning port to the socket, so warnings about expressions typed on a
> REPL server were being sent to the main program's stderr.  I fixed this
> in 5e74217c7cf07ad474cdce1a01e049492e7ef1b7, but if we add another port
> parameter I'll have to fix that in at least two places now: server.scm
> and coop-server.scm.
>
> I wonder if external code needs to sometimes do this as well.  How will
> they cope with a periodically-expanding set of port parameters, while
> retaining compatible with older versions of guile that lack some of
> them?  Should we add a 'parameterize-all-stdout-like-ports' macro?

It occurs to me that one possibility would be to allow some of these
parameters to effectively mirror the value of some other parameter.

For example, the 'current-notification-port' parameter could mirror the
'current-warning-port' parameter by default, which could in turn mirror
the 'current-error-port' parameter by default.

One way to implement this would be to make the corresponding fluid be a
thunk that returns a port, instead of the port itself.  The converter
could accept either a port or a parameter, and convert each of these to
a suitable thunk.  Finally, we'd make custom 'current-warning-port' and
'current-error-port' procedures that would handling calling the thunk.

Of course, this extra complexity would make these parameters inherently
more expensive, so it would only be appropriate for these special
seldom-used port parameters.  However, for these cases it might be a
worthwhile extension.  In one commit we could fix a number of possible
bugs (similar to the one fixed by 5e74217) that might well exist in
external code.

What do you think?

      Mark