Re: Proposed new core library: alert.el

[Eli Zaretskii]

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

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

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

Who sets up the handler in that scenario?

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

What should be in the metadata?

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

That's just the infrastructure, AFAICT.  The other part, i.e., what
you describe in 2) above, still needs to be written, for this to be
ready to use.  Right?