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

[Mark H Weaver]

address@hidden (Ludovic Courtès) writes:

> Andy Wingo <address@hidden> skribis:
>
>> On Sun 02 Mar 2014 22:13, address@hidden (Ludovic Courtès) writes:
>>
>>> FWIW, I think the approach should rather be to have a special port (a
>>> fluid) for such things, say, ‘current-notification-port’.  We’d simply
>>> replace scm_current_error_port by scm_current_notication_port above.
>>
>> Isn't that the same as current-warning-port?  I thought this was one of
>> the use cases for current-warning-port :)
>
> Yeah it’s very similar, but we could want to differentiate between
> actual warnings and mere notifications.  Dunno if it’s important.

One issue worth thinking about is that there are cases where code has to
parameterize all of these port parameters.

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?

     Mark