Re: Proposed new core library: alert.el

[Ted Zlatanov]

On Fri, 06 Nov 2015 17:52:21 +0200 Eli Zaretskii <address@hidden> wrote: 

>> From: Ted Zlatanov <address@hidden>
>> Date: Fri, 06 Nov 2015 10:32:33 -0500
>> 
>> On Fri, 06 Nov 2015 12:04:48 +0200 Eli Zaretskii <address@hidden> wrote: 
>> 
EZ> I think it would make sense to provide an intermediate
EZ> platform-independent layer for displaying alerts
>> 
>> Yes, this is simply a `message' call.

EZ> If 'message' could be told to display notifications, yes.  But what
EZ> you say is just the design; someone should write the code to implement
EZ> it.

I will, but gave you and others a chance to review my plan.

>> I think the only thing missing is metadata and I would draw
>> inspiration from syslog: level, facility, and tags. Then the
>> *handler* should decide what to do with the message based on the
>> metadata.

EZ> Who sets up the handler in that scenario?

After you install alert.el, you customize `message-handler' to
`alert-message-handler'.  The `message' function remains the same in C
but gets diverted at the very top to a Lisp function.

Artur's alternate proposal is to divert `message' itself through a variable.

>> I'm not sure how to provide the metadata, and it should be ignored by
>> the default (current) message handler.  Maybe it could be string
>> properties applied to the first parameter?  I *need* to know this before
>> writing code.

EZ> What should be in the metadata?

As I mentioned, the syslog-style metadata is probably enough: level,
facility, and tags.

>> So before I jump to implementation, this is the design I'm considering:
...
EZ> That's just the infrastructure, AFAICT.  The other part, i.e., what
EZ> you describe in 2) above, still needs to be written, for this to be
EZ> ready to use.  Right?

Yes, but the C changes can be made sooner and with less hassle.  They
are a new feature, too, so the whole thing may have to wait.

On Fri, 6 Nov 2015 16:01:03 +0000 Artur Malabarba <address@hidden> wrote: 

AM> While related to the original alert.el proposal, this is a whole new
AM> discussion. Could we branch it off to another subject?

Is there an alternate plan to bring in just alert.el?  If not, maybe we
can stay in the same thread...

AM> I created another thread (called "Redirecting messages") with a
AM> proposal as well. It's similar to Ted's, but with many small
AM> differences.

I just saw it, thank you. I think they are similar enough that it
doesn't matter much which one we use, and my proposal is slightly simpler.
So unless you have strong feelings about it, let's go with mine?

Ted