[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
#'message-echo-area
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.
- Redirecting messages (was: Proposed new core library: alert.el),
Artur Malabarba <=