|
From: | Sjoerd van Leent |
Subject: | Re: Discussion for %display-auto-compilation-messages (and --no-auto-compilation-messages option) |
Date: | Mon, 03 Mar 2014 16:17:46 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 |
I see where you are going and personally, I like the suggestion.In any case, couldn't there be an approach similar to those used with most logging frameworks. In GLib, there are the following options:
G_LOG_LEVEL_ERROR G_LOG_LEVEL_CRITICAL G_LOG_LEVEL_WARNING G_LOG_LEVEL_MESSAGE G_LOG_LEVEL_INFO G_LOG_LEVEL_DEBUGI have no clue yet which ports exist, aside from (current-output-port), (current-warning-port) and (current-error-port).
I imagine to create 5 virtual ports: (current-debug-port), (current-info-port), (current-message-port), (current-warning-port) and (current-critical-port). These would either be hooked up to the (current-output-port), except for (current-critical-port) which should be hooked up to (current-error-port).
The normal guile operation would be to have warning, critical and error messages to be fired. Guile should then get two additional options:
--verbosity=<level>, where level should be "debug", "info", "message", "warning", "critical" and "error". --quiet, which suggests to skipp verbosity altogether and to display nothing anymore aside from writes to (current-output-port).
Guile should by default function in the "info" verbosity mode.If verbosity is a nice fluid, one could change the verbosity level when deemed necessary.
And I would be happy to work this out. On 03/02/14 22:13, Ludovic Courtès wrote:
Hi, Sjoerd van Leent <address@hidden> skribis:- scm_puts_unlocked (";;; compiling ", scm_current_error_port ()); - scm_display (source, scm_current_error_port ()); - scm_newline (scm_current_error_port ()); + if (scm_is_true (*scm_loc_display_auto_compilation_messages)) + { + scm_puts_unlocked (";;; compiling ", scm_current_error_port ()); + scm_display (source, scm_current_error_port ()); + scm_newline (scm_current_error_port ()); + }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. The command-line option could be --quiet. It would bind both current-notification-port and current-warning-port to a void port. WDYT? Would you like to adjust the patch accordingly? Thanks, Ludo’.
[Prev in Thread] | Current Thread | [Next in Thread] |