On Sun, Apr 30, 2006 at 08:35:38PM -0700, Ben Pfaff wrote:
John Darrington <[EMAIL PROTECTED]> writes:
> 1. There'll be a new construct, which I'll call a "message context".
I'm still planning to add better support for reporting where a
message is coming from, and I was going to call my description of
that a "message context". But I can call it an "origin" or
"location" instead.
It sounds like we're both tackling the same general problem. What do
you mean by "where a message is coming from" ? The function which
calls msg is not very helpful, as many functions could call that
function. A complete stack trace up to the time that the message was
called would contain a lot of information, but would be too verbose
to helpful.
Hence my idea of allowing the user interface to define the
boundaries delimiting the different classes of situations in which a
messages may be generated. If we go down the path of multi-threaded
user interfaces, then it would certainly be useful for the message
struct to contain a member identifying the thread which generated it.
> Further, a context can specify the manner in which messages are
> reported, eg: dialog box, scrolled list, log file or combination
> thereof.
I was planning to put reporting of errors to the listing file at
a layer below the reporting to the callback. Obviously this
doesn't mesh with your plans. I'll have to do something else,
then; perhaps the callback is responsible for deciding what, if
any, errors should be reported to the listing file.
Yes. I think that's probably best. In my model, I would push a new
message context when I start parsing a syntax file, and pop it, when
complete. In that context, messages would be reported to the listing
file (and probably elsewhere too).
J'
--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.
signature.asc
Description: Digital signature
_______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
