[Top][All Lists]

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

Re: Proposed new core library: alert.el

From: Ted Zlatanov
Subject: Re: Proposed new core library: alert.el
Date: Sat, 07 Nov 2015 07:28:39 -0500
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux)

On Fri, 06 Nov 2015 20:04:49 -0500 "John Wiegley" <address@hidden> wrote: 

>>>>>> Ted Zlatanov <address@hidden> writes:
>> Yes, this is simply a `message' call. 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.

>> 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.

JW> Ted, I must have missed where this discussion about metadata came up. 
JW> already has a facility for passing and consuming metadata. Would there be a
JW> need to consider another scheme also?

OK, let me explain.  Looking at alert.el.  The severity is good, same as syslog.

There is no facility or tags in alert.el (although I think :type and
:category sort of map to those syslog terms).

Most importantly, alert.el takes a plist, which is not compatible with
`message'. To make it a standard interface, it should just take a string
(with possibly some other parameters for `format'), hence my proposal to
take the plist entries and pass them as string properties to the one
required parameter. From alert.el, the work required would be to provide
a `alert-message-handler' function which takes that string and converts
it to the plist format.

So (message "mystring-with-properties" x y z) where the string has
properties :severity 'foo :facility 'bar would get eventually translated
to an alert call that extracted the properties from
"mystring-with-properties" to yield

    (alert "mystring-with-properties" :severity 'foo :type 'bar)

I think the alternative would be to allow `message' to take a plist,
which I don't think is as good, and would still require translation from
`message' generic properties 

I hope that explains it.


reply via email to

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