Re: Proposed new core library: alert.el

[Ted Zlatanov]

On Fri, 06 Nov 2015 16:38:04 -0500 Richard Stallman <address@hidden> wrote: 

RS> We have a rather general feature for displaying warnings:
RS> the function `display-warning'.  Could it serve this purpose?

RS> Could it be extended to serve this purpose?

Maybe.  I honestly wasn't aware of it.  I'm not sure why John didn't use
that interface, probably he didn't know about it either.  It's really
not very popular among module authors.

RS> In principle, it would be nice to have just one such mechanism
RS> rather than two.

Well, we currently have the `message' interface (format string + format
parameters) and the `display-warning' interface.  I agree it would be
nice to merge them, perhaps by using properties on the format string.

See beow for my concrete proposal.

On Fri, 06 Nov 2015 16:20:03 -0500 John Wiegley <address@hidden> wrote: 

JW> At this point I think we have three proposals, so if we still don't have
JW> consensus by the weekend, let's use the new Emacs Wiki Proposals index to
JW> summarize the alternatives for people to review.

Sure.  I'll try to get to consensus.  I really don't have a "favorite"
proposal as you'll see below.

On Sat, 7 Nov 2015 18:40:18 +0800 Elias Mårtenson <address@hidden> wrote: 

EM> On 6 Nov 2015 11:33 p.m., "Ted Zlatanov" <address@hidden> wrote:

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

EM> How about using CL-style keyword parameters?

EM> Like: (message "hello" :source x :priority y)

That is not compatible with the current `message' interface, but is
exactly what alert.el uses. OTOH `display-warning' uses positional
parameters for severity etc. So we have three possible interfaces.

I propose to flatten them all into `message' using a string with
properties as I mentioned earlier.  The default `message' handler in
Emacs will unpack the properties appropriately for `display-warning' and
use the standard Fmessage() if there are no properties.

An alternative `message' handler like the plausible one from alert.el
would unpack the properties into a plist and pass them to alert.el.

So we'd have:

1) default message handler, most common case:
    (message "simple string") -> Fmessage()

2) default message handler, with properties:
    (message "string-with-properties") -> (display-warning ...)

3) alert.el message handler, most common case:
    (message "simple string") -> `alert' or Fmessage() depending on alert.el 
rules

4) alert.el message handler, with properties
    (message "string-with-properties") -> (alert ...)

Does all of that make sense?  Ultimately my goal is to have a single
sensible interface, not to bikeshed this to death.

On Fri, 6 Nov 2015 19:03:00 +0000 Artur Malabarba <address@hidden> wrote: 

AM> Maybe we're miscommunicating. I don't propose to change the current
AM> behavior in any way. In fact, the outcome of my proposal should be
AM> identical to yours. I'm just saying "instead of having the current
AM> behavior correspond to a nil value of the variable, have it correspond
AM> to a proper function value".
...
AM> I am replacing the value of the variable
AM> font-lock-fontify-region-function, with a function that calls the
AM> original value and then calls my function. I couldn't do that if its
AM> default value were nil.

(sorry for bringing things back to the main thread but I don't want
several replies)

OK, I'm convinced.  But now the problem is that `display-warning' is a
third interface to messages and warnings.  So if you agree with my call
interface above, then yes, the message handler should be a variable as
you suggested.

Ted