pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Messages again


From: John Darrington
Subject: Re: Messages again
Date: Mon, 1 May 2006 15:00:14 +0800
User-agent: Mutt/1.5.9i

On Sun, Apr 30, 2006 at 08:35:38PM -0700, Ben Pfaff wrote:
     John Darrington <address@hidden> 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.


Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]