Re: Proposed new core library: alert.el

[Artur Malabarba <bruce.connor.am@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On 8 Nov 2015 8:49 pm, "Ted Zlatanov" <tzz@lifelogs.com> 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. 👍

[-- Attachment #2: Type: text/html, Size: 1853 bytes --]