Re: Proposed new core library: alert.el

[Artur Malabarba]

> On Fri, 6 Nov 2015 16:01:03 +0000 Artur Malabarba <address@hidden> wrote:
>
> AM> While related to the original alert.el proposal, this is a whole new
> AM> discussion. Could we branch it off to another subject?
>
> Is there an alternate plan to bring in just alert.el?  If not, maybe we
> can stay in the same thread...

Redirecting messages is something that's come up before, and other
people who aren't following this thread might be interested. By
keeping the discussion here, we're hiding it from other people.

I'd really appreciate it if we branch off subjects more often. And I'm
not the only one, there was a short thread on this just a couple of
days ago.

> AM> I created another thread (called "Redirecting messages") with a
> AM> proposal as well. It's similar to Ted's, but with many small
> AM> differences.
>
> I just saw it, thank you. I think they are similar enough that it
> doesn't matter much which one we use, and my proposal is slightly simpler.
> So unless you have strong feelings about it, let's go with mine?

I'm cool with your proposal too, so feel free to go ahead.
There are just 2 points I do feel rather strongly about.
1. The variable name should end in `-function', not `-handler' (that's
just the convention Emacs uses).
2. The variable's default value should be a function (which implements
the default behaviour), not nil.

Allowing a nil value is just going to make it harder for
users/packages to use the `add-function' mechanisms on this variable.
For instance, see the variable `font-lock-fontify-region-function'.
Its name ends in `-function', and its default value is
#'font-lock-default-fontify-region. That's the convention we should
follow with these variables.