[Top][All Lists]
[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.
signature.asc
Description: Digital signature
- Re: Messages again,
John Darrington <=