Re: Proposed new core library: alert.el

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 06 Nov 2015 12:04:48 +0200 Eli Zaretskii <eliz@gnu.org> 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. 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.

So before I jump to implementation, this is the design I'm considering:

1) make a new `message-handler' buffer-local variable, default to nil, customizable
1.1) maybe buffer local is not necessary?  I'm not sure what's best.

2) users and packages can override `message-handler' as needed:
    (setq message-handler 'alert-message-handler)

3) in the C code, `editfns.c:Fmessage' will check for `message-handler'
and if it exists, simply call it with all the parameters and exit

4) the handlers do not have to preserve the `message' specific behavior,
as shown in its docstring, e.g. printing to STDERR in batch mode or
clearing an existing message when passed nil.

Once that piece is done, alert.el can be adjusted as needed; the
metadata passing is the major piece missing.  Sounds good?

On Thu, 05 Nov 2015 17:47:18 -0800 raman <raman@google.com> wrote: 

r> You could do this seamlessly by attaching an around advice to message
r> and having that call alert

We could, but won't :)

Ted