Re: Proposed new core library: alert.el

[Artur Malabarba]

On 8 Nov 2015 8:49 pm, "Ted Zlatanov" <address@hidden> wrote:
> After sleeping on it, I think the third and best way is to put the
> properties first. Since `message' expects a FORMAT-STRING first, this is
> unambiguous and the property pairs can be removed before passing the string
> and the rest of the parameters down to `format'. In particular, it means
> that partial application with `apply-partially' will work nicely because
> the caller can pack the metadata at the beginning of the parameters. It
> also degrades gracefully to the current call convention.

It will be a bit of a shame that code written this way won't be backwards compatible, but I think I agree with you that it's better like this. After sleeping on it too I realised that it would be an ugly implementation, and while I like to facilitate compatibility, the core code shouldn't suffer for it.

So 👍.

> So, here's my revised proposal:
>
> 1) default message handler, most common case:
>     (message "simple string") -> no metadata -> Fmessage()
>
> 2) default message handler, with metadata:
>     (message :severity 'urgent "string") -> (display-warning ...)
>
> 3) installed alert.el message handler, most common case:
>     (message "simple string") -> `alert' or Fmessage() depending on alert.el rules
>
> 4) alert.el message handler, with metadata
>     (message :severity 'urgent "string") -> (alert "string" :severity 'urgent)

Sounds good. 👍