[Top][All Lists]

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

Redirecting messages (was: Proposed new core library: alert.el)

From: Artur Malabarba
Subject: Redirecting messages (was: Proposed new core library: alert.el)
Date: Fri, 6 Nov 2015 09:23:49 +0000

On 5 Nov 2015 7:48 pm, "Ted Zlatanov" <address@hidden> wrote:
> Agreed.  But if alert.el doesn't support it now, it should have a way to
> replace `message' so rather than asking every package to change, the
> user just customizes one thing globally.

I don't think users will want to turn every single message into a
desktop notification. The `message' function has always been a very
non-intrusive approach, so it's used in very spammy ways sometimes.

That said, a way of redirecting messages via some arbitrary function
is something that would be nice to have, and it's been mentioned
lately here. I think Stefan was pushing for this a bit, specially when
Oleh implemented the new inhibit-messages variable.

The right approach IMO is to

1. move the current message function to `message-echo-area'
2. define a variable called `message-function', whose default value is
3. redefine the `message' function to just call the value of
`message-function' and then log the string to the  *Messages* buffer

I think this logging shouldn't be moved to a separate thing (like the
echo-area) because there's already a variable called `message-log-max'
to disable it, and because I think most uses of changing
`message-function' will want to preserve the logging. One option is to
say that the value returned by `message-function' will be logged to
the `*Messages*' buffer, so the function can always return nil if it
doesn't want logging.

If we do this we should remove the inhibit-messages variable, since
it's equivalent to binding message-function to #'ignore.

reply via email to

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