message-function (was: Proposed new core library: alert.el)

[Ted Zlatanov]

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

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

I think "hiding" is a strong word for it.

I am also not keen on a 3-month discussion of this simple change.

AM> I'm cool with your proposal too, so feel free to go ahead.

AM> There are just 2 points I do feel rather strongly about.
AM> 1. The variable name should end in `-function', not `-handler' (that's
AM> just the convention Emacs uses).

OK, it will be `message-function'.

AM> 2. The variable's default value should be a function (which implements
AM> the default behaviour), not nil.

Well, your point (2) is not exactly what I think is best. Your proposal
requires a new `message-function-standard' name for the internal
Fmessage(), and changes the current `message' completely.

By contrast, my proposal has `message' calling Fmessage() (the current
behavior) and then, iff `message-function' is set, doing something
different. So it preserves the current behavior exactly. I think that's
an important consideration for changing a very fundamental Emacs function.

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

If the user wants to `add-function' on `message', they should
`add-function' on `message'.  I don't see why they care that
`message-function' is nil or something else.  But maybe I'm missing
something here.  I've been away from Emacs development for a bit.

Ted