[Top][All Lists]

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

Re: Proposed new core library: alert.el

From: Artur Malabarba
Subject: Re: Proposed new core library: alert.el
Date: Mon, 9 Nov 2015 00:03:14 +0000

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

reply via email to

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