Date: Fri, 9 Jun 2000 08:50:21 -0700
From: Russell E Owen
Subject: Re: Changes in operator's use of TCC 2.3
At 6:36 PM -0600 6/8/00, Russet McMillan wrote:
>  >Remember that ALL replies to your own commands show up in the 2nd
>>window -- giving you time to admire their output without a bunch of
>>other messages scrolling them off screen or getting mixed up into
>>them. Great for displaying status and such.
>
>But they don't.  We've found commands (basically just typos, so far,
>but we only experimented a little) where only part of the output is
>displayed in the window where the command originated, if that window
>has MSGFILT on.  The only lines that appeared were the ones with F and
>W, and other lines were left out of the *originating* window.  This is
>a problem -- if it happens for anything other than typos, it's a
>serious problem.
That's right. Darn. Some messages are anonymous (have user # = 0),
and if they have level "information" then they will not get through
the filter.
As it stands, you are guaranteed to see the final completion notice
-- error or success. If something goes wrong, some of the messages
will be anonymous, but if your filter is set to WARNING then you will
see almost all the important ones (just missing the occasional
INFORMATION message that might have helped figure out what was going
on).
I will try to fill in the holes -- make sure more and more relevant
messages are tagged correctly instead of being anonymous. A total fix
is impractical because it requires rewriting too many subroutines to
include message tag as an input, but I can certainly get the worst
cases fixed, especially if folks report them.
Meanwhile, setting filter level to WARNING is the only sensible thing
to do. ERROR and NONE will miss too much.
The root of the problem is that our messaging protocol (I, W, etc.)
only permits one error message (F) per command -- that terminates the
command replies telling you the command failed (as opposed to ":",
which tells you it succeeded and finished).
I often want to report problems at several levels -- in the
subroutine that first detected them, and then supplemental
explanation. There isn't any really good mechanism for this in the
messaging protocol. What I've done in the past is use anonymous
errors (0 0 F -- i.e. no command or user number). Lately I've been
moving towards tagged warnings, instead. Warnings are really supposed
to mean "problem, but I'll continue anyway", but their meaning can be
twisted to fit this case ("problem, I may or may not be able to
continue, somebody else will tell you").
-- Russell