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

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

[Artur Malabarba]

On 5 Nov 2015 7:48 pm, "Ted Zlatanov" <tzz@lifelogs.com> 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.

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

On 11/06/2015 01:23 AM, Artur Malabarba wrote:
> On 5 Nov 2015 7:48 pm, "Ted Zlatanov" <tzz@lifelogs.com> 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 wish we'd direct some love toward the streams system. There's no
reason that standard-output and a hypothetical message-output couldn't
be the same type of object and have the same semantics. A scheme like
this would also help modes like ielm provide a uniform way of capturing
command output.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

File-handle streams (was: Redirecting messages)

[John Wiegley]

>>>>> Daniel Colascione <dancol@dancol.org> writes:

> I wish we'd direct some love toward the streams system. There's no reason
> that standard-output and a hypothetical message-output couldn't be the same
> type of object and have the same semantics. A scheme like this would also
> help modes like ielm provide a uniform way of capturing command output.

I want this too, Daniel. I'd also like to have a way of making streams from
file handles directly, so Eshell could finally support input redirection.
Something like:

    (with-file-stream "/tmp/foo" :mode 'write :var handle
       (prin1 some-object handle))

At the moment it's rather hard to generate huge amounts of data to a file
quickly, since you have to use a buffer in between. Eshell's piping behavior
would also be orders of magnitude faster, since it now uses a temporary buffer
to accumulate and then send data from one process to another.

Anyone interested in tackling this challenge?

John

Re: Redirecting messages

[Rasmus]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> On 5 Nov 2015 7:48 pm, "Ted Zlatanov" <tzz@lifelogs.com> 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.

Indeed, this would be nice.  I would like to be able to be notified when a
time-consuming R script has completed or when Org is done compiling my
PDF; tramp is done copying many files, etc.

Perhaps it would be nice if the default would already check some custom
variable consisting of cons of

      (FUN or regexp for evaluating message . FUN or String to notify)

Or each user can add this in her own custom message function.

Rasmus

-- 
ツ

Re: Redirecting messages

[John Wiegley]

>>>>> Rasmus  <rasmus@gmx.us> writes:

> Perhaps it would be nice if the default would already check some custom
> variable consisting of cons of

>       (FUN or regexp for evaluating message . FUN or String to notify)

> Or each user can add this in her own custom message function.

This type of functionality is exactly what alert.el does. :) If we redefine
message to be alert, with alert's default being to call the old message,
you'll be able to take complete control over how you get notified, and when.

John

Re: Redirecting messages

[John Wiegley]

>>>>> Artur Malabarba <bruce.connor.am@gmail.com> writes:

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

I agree, Artur. alerts are meant to be "things you should be aware of", while
`messages' are often used for informational data you don't need to know about
until you read the activity trace in *Messages*.

That said, if we define message = alert, we could make the default severity be
`trivial', so that alert = message. Only severities above, say, normal, would
cause desktop notifications to begin by default.

Another thing we could do is automatically tag all messages based on the
feature they originated from. That way, users could choose to escalate
messages based on REGEXP+FEATURE, allowing packages that do not provide
severity information to be retroactively treated as if they had.

John

Re: Redirecting messages

[raman]

1+ on tagging alert messages with metadata as to where they came from -- 
-- 

Re: Redirecting messages

[John Wiegley]

>>>>> Artur Malabarba <bruce.connor.am@gmail.com> writes:

> 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

Maybe we can do something even simpler:

 1. Rename `message' to `message-echo-area'.

 2. (defalias 'message 'alert)

 3. alert's default severity is `normal'.

 4. Have alert's default behavior for `normal' be to call `message-echo-area'
    (i.e., don't log to *Alerts*, don't do anything else).

 5. Optionally, inject a :file parameter to `alert' (as a hack) to identify
    which Elisp file the alert came from.

    Alternatively, we could provide a general mechanism allowing Elisp
    functions to determine the file/line/feature of the function that called
    them (when such information is available). Maybe this already exists?

 6. Document how to enable different backends at higher severities. Or,
    default to message+log for such messages, but with a bold color, and so
    they also appear in *Alerts* with a timestamp.

This gives us, for the default case, the same behavior we have today. Users
can then choose different backends for different scenarios, such as matching
on regexp, or by severity, to get rich notifications as they wish.

In the future it would be nice if package authors provided more metadata, but
this might not be necessary if we have regexps and know the source location.

John