Re: Proposed new core library: alert.el

[Ted Zlatanov <tzz@lifelogs.com>]

On Sat, 07 Nov 2015 08:44:34 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sat, 7 Nov 2015 13:09:39 +0000 Artur Malabarba <bruce.connor.am@gmail.com> wrote: 
AM> We can still use a plist if we want, as long as it comes after all of
AM> the format arguments:

AM> (message "Hi %s, I'm %s." 'ted 'artur
AM> :severity :urgent)

TZ> From experience, I think it's a bad programming practice to abuse a
TZ> function's interface (`message' mapped to `format' in this case) to
TZ> extend it.

TZ> OTOH Artur's approach makes it much easier to see what properties are
TZ> provided instead of hiding them inside the string.

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.

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)

As far as the actual mechanics of the message handler function, I'll say
again that I think Artur's proposal makes the most sense.

Artur and others, let me know what you think.

Ted