Is there a way to inhibit message3 from Elisp?

Is there a way to inhibit message3 from Elisp?

[Oleh Krehel]

Hi all,

I think this option would be quite useful in general, if it's not yet
implemented, which I'm pretty sure it's not.

My particular use-case is that I'm doing completion in the minibuffer
with ivy.el, calling `shell-command-to-string' in the `post-command-hook'.
And when I enable `while-no-input' in my function, my minibuffer
contents get rudely interrupted by `call_process_cleanup' saying:

> "Waiting for process to die...done"

I'm sure that this message is needed and appericated, but I'd like to
have an option to suppress it. I think a variable like `inhibit-message'
that I could let-bind would be a good solution to my problem.

I've seen this question brought up a few times on the stack exchange
sites, what people tend to do is to `flet'-override the `message'
function.  It doesn't apply in this case, but the solution to this
problem would solve the other ones too.

Oleh

Re: Is there a way to inhibit message3 from Elisp?

[Stefan Monnier]

> My particular use-case is that I'm doing completion in the minibuffer
> with ivy.el, calling `shell-command-to-string' in the `post-command-hook'.
> And when I enable `while-no-input' in my function, my minibuffer
> contents get rudely interrupted by `call_process_cleanup' saying:
>> "Waiting for process to die...done"
> I'm sure that this message is needed and appericated,

Actually, I'm not.  IIUC this message appears if a call-process is
interrupted before the subprocess dies.   I think this message in not
desired in general.  It's OK to emit such a message if call-process ends
up waiting a non-negligible amount of time for the subprocess to die
(so as to explain to the user why Emacs is not responding), but for the
usual case where wait_for_termination returns quickly, we should not
emit any message at all.

Patch welcome to fix this problem.

> but I'd like to have an option to suppress it.  I think a variable like
> `inhibit-message' that I could let-bind would be a good solution to
> my problem.

I recently suggested to introduce a message-redirection variable, which
would provide a superset of what you want.  Patch welcome as well.


        Stefan

Re: Is there a way to inhibit message3 from Elisp?

[Oleh Krehel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> My particular use-case is that I'm doing completion in the minibuffer
>> with ivy.el, calling `shell-command-to-string' in the `post-command-hook'.
>> And when I enable `while-no-input' in my function, my minibuffer
>> contents get rudely interrupted by `call_process_cleanup' saying:
>>> "Waiting for process to die...done"
>> I'm sure that this message is needed and appericated,
>
> Actually, I'm not.  IIUC this message appears if a call-process is
> interrupted before the subprocess dies.   I think this message in not
> desired in general.  It's OK to emit such a message if call-process ends
> up waiting a non-negligible amount of time for the subprocess to die
> (so as to explain to the user why Emacs is not responding), but for the
> usual case where wait_for_termination returns quickly, we should not
> emit any message at all.
>
> Patch welcome to fix this problem.

Please check the scratch/inhibit-message3 branch.
I don't have experience with Emacs C code, let me know if I'm doing
something in a silly way.

I got this code to work as I expect:

(progn
  (setq inhibit-message t)
  (message "foo")
  (setq inhibit-message nil))

However, this doesn't work:

(let ((inhibit-message t))
  (message "foo"))

And I don't know why.

Oleh

Re: Is there a way to inhibit message3 from Elisp?

[Artur Malabarba]

That C code is a little hard for me to understand, but it looks like
you're inhibitting both echoing (minibuffer) and logging (messages
buffer). If that's the case, please don't inhibit the latter.

2015-04-21 19:50 GMT+01:00 Oleh Krehel <ohwoeowho@gmail.com>:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> My particular use-case is that I'm doing completion in the minibuffer
>>> with ivy.el, calling `shell-command-to-string' in the `post-command-hook'.
>>> And when I enable `while-no-input' in my function, my minibuffer
>>> contents get rudely interrupted by `call_process_cleanup' saying:
>>>> "Waiting for process to die...done"
>>> I'm sure that this message is needed and appericated,
>>
>> Actually, I'm not.  IIUC this message appears if a call-process is
>> interrupted before the subprocess dies.   I think this message in not
>> desired in general.  It's OK to emit such a message if call-process ends
>> up waiting a non-negligible amount of time for the subprocess to die
>> (so as to explain to the user why Emacs is not responding), but for the
>> usual case where wait_for_termination returns quickly, we should not
>> emit any message at all.
>>
>> Patch welcome to fix this problem.
>
> Please check the scratch/inhibit-message3 branch.
> I don't have experience with Emacs C code, let me know if I'm doing
> something in a silly way.
>
> I got this code to work as I expect:
>
> (progn
>   (setq inhibit-message t)
>   (message "foo")
>   (setq inhibit-message nil))
>
> However, this doesn't work:
>
> (let ((inhibit-message t))
>   (message "foo"))
>
> And I don't know why.
>
> Oleh
>

Re: Is there a way to inhibit message3 from Elisp?

[Oleh Krehel]

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

> That C code is a little hard for me to understand, but it looks like
> you're inhibitting both echoing (minibuffer) and logging (messages
> buffer). If that's the case, please don't inhibit the latter.

OK, updated.

Oleh

Re: Is there a way to inhibit message3 from Elisp?

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Date: Tue, 21 Apr 2015 20:50:59 +0200
> Cc: emacs-devel@gnu.org
> 
> Please check the scratch/inhibit-message3 branch.
> I don't have experience with Emacs C code, let me know if I'm doing
> something in a silly way.

Some comments below.

> I got this code to work as I expect:
> 
> (progn
>   (setq inhibit-message t)
>   (message "foo")
>   (setq inhibit-message nil))
> 
> However, this doesn't work:
> 
> (let ((inhibit-message t))
>   (message "foo"))

How does it "not work"?  It did for me.

Some comments for the changes:

  . This variable is a boolean, so it's better to use DEFVAR_BOOL
    instead of DEFVAR_LISP.  (Don't forget to change the test in
    message3 accordingly.)

  . The Emacs coding conventions are to use this:

      if (something)
        {
	  do_whatever ();
	}

    rather than this:

      if (something) {
        do_whatever ();
      }

    Besides, when there's only one statement after 'if', you don't
    need the braces at all.

  . With your last change, the doc string is misleading, and should be
    updated.

  . The change should be accompanied by an entry in etc/NEWS.  Bonus
    points for updating the ELisp manual as well.

Thanks for working on this.

Re: Is there a way to inhibit message3 from Elisp?

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:
>> I got this code to work as I expect:
>> 
>> (progn
>>   (setq inhibit-message t)
>>   (message "foo")
>>   (setq inhibit-message nil))
>> 
>> However, this doesn't work:
>> 
>> (let ((inhibit-message t))
>>   (message "foo"))
>
> How does it "not work"?  It did for me.

I misunderstood that when "C-x C-e" would not print the message in
*scratch*. But otherwise, it works.

> Some comments for the changes:
>
>   . This variable is a boolean, so it's better to use DEFVAR_BOOL
>     instead of DEFVAR_LISP.  (Don't forget to change the test in
>     message3 accordingly.)
>
>   . The Emacs coding conventions are to use this:
>
>       if (something)
>         {
> 	  do_whatever ();
> 	}
>
>     rather than this:
>
>       if (something) {
>         do_whatever ();
>       }
>
>     Besides, when there's only one statement after 'if', you don't
>     need the braces at all.

OK.

>   . With your last change, the doc string is misleading, and should be
>     updated.

Updated.

>   . The change should be accompanied by an entry in etc/NEWS.  Bonus
>     points for updating the ELisp manual as well.

Updated etc/NEWS and the manual (entry for `message').
Let me know if it's OK to merge.

Oleh

Re: Is there a way to inhibit message3 from Elisp?

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 22 Apr 2015 13:55:42 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> I got this code to work as I expect:
> >> 
> >> (progn
> >>   (setq inhibit-message t)
> >>   (message "foo")
> >>   (setq inhibit-message nil))
> >> 
> >> However, this doesn't work:
> >> 
> >> (let ((inhibit-message t))
> >>   (message "foo"))
> >
> > How does it "not work"?  It did for me.
> 
> I misunderstood that when "C-x C-e" would not print the message in
> *scratch*. But otherwise, it works.

I used C-j instead, and it correctly inserts the message into
*Messages*, but does not display it in the echo area.

> Updated etc/NEWS and the manual (entry for `message').
> Let me know if it's OK to merge.

I think it's OK, with a few minor comments:

  +** New variable `inhibit-message', when bound to t, inhibits the
                                                 ^^^^
"non-nil" is more accurate (please make the same change in the manual
as well)

  +   message3 C function from using the Echo Area. The output is still
  +   logged to the *Messages* buffer.

First, we use 2 spaces between sentences, per US English conventions.

More importantly, NEWS is supposed to be read by Lisp-level users, so
talking about C-level details is not useful.  Please talk about the
'message' function instead.  Also, "using the Echo Area" is too vague;
better say "displaying messages in the Echo Area".

Finally, if the change is documented in the manual, it should be
marked with "+++", see the explanations at the beginning of NEWS.

  +When @code{inhibit-message} is @code{t}, no message will be displayed
  +in the echo area, it will only be logged to @file{*Messages*}.

"*Messages*" is not a file, so please use the @samp markup.

Also, please document this explicitly as a variable, using @defvar, so
that it gets indexed as all the other variables.  There are examples
of its usage in the manual.

Re: Is there a way to inhibit message3 from Elisp?

[Oleh Krehel]

Thanks for the comments, Eli. I attach a squashed patch.
Please check again if it's alright.

Oleh

===File
/home/oleh/git/gnu-emacs/0001-Add-a-new-inhibit-message-variable.patch===
From 95015bef323d1cc7c935a676a6526995ea0a3ca9 Mon Sep 17 00:00:00 2001
From: Oleh Krehel <ohwoeowho@gmail.com>
Date: Wed, 22 Apr 2015 14:45:09 +0200
Subject: [PATCH] Add a new `inhibit-message' variable

* src/xdisp.c (syms_of_xdisp): Define a boolean `inhibit_message'.
(message3): Don't call `message3_nolog' (i.e. use the Echo Area) when
`inhibit_message' is non-zero.

* etc/NEWS: Add an entry.

* doc/lispref/display.texi: Add an entry for `inhibit-message',
  mention it in `message'.
---
 doc/lispref/display.texi | 8 ++++++++
 etc/NEWS                 | 5 +++++
 src/xdisp.c              | 9 +++++++--
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi
index e2a38b6..f86149d 100644
--- a/doc/lispref/display.texi
+++ b/doc/lispref/display.texi
@@ -257,6 +257,9 @@ text properties (@pxref{Logging Messages}).
 In batch mode, the message is printed to the standard error stream,
 followed by a newline.
 
+When @code{inhibit-message} is non-nil, no message will be displayed
+in the echo area, it will only be logged to @samp{*Messages*}.
+
 If @var{format-string} is @code{nil} or the empty string,
 @code{message} clears the echo area; if the echo area has been
 expanded automatically, this brings it back to its normal size.  If
@@ -282,6 +285,11 @@ To automatically display a message in the echo area or in a pop-buffer,
 depending on its size, use @code{display-message-or-buffer} (see below).
 @end defun
 
+@defvar inhibit-message
+When this variable is non-nil, @code{message} and related functions
+will not use the Echo Area to display messages.
+@end defvar
+
 @defmac with-temp-message message &rest body
 This construct displays a message in the echo area temporarily, during
 the execution of @var{body}.  It displays @var{message}, executes
diff --git a/etc/NEWS b/etc/NEWS
index 804b819..e2b6b11 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -200,6 +200,11 @@ font, and (iii) the specified window.
 
 ** New possible value for `system-type': nacl.
 
++++
+** New variable `inhibit-message', when bound to non-nil, inhibits
+   `message' and related functions from displaying messages the Echo
+   Area.  The output is still logged to the *Messages* buffer.
+
 \f
 * Editing Changes in Emacs 25.1
 
diff --git a/src/xdisp.c b/src/xdisp.c
index a17f5a9..6ca1906 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -10053,8 +10053,8 @@ message3 (Lisp_Object m)
       message_dolog (buffer, nbytes, true, multibyte);
       SAFE_FREE ();
     }
-  message3_nolog (m);
-
+  if (! inhibit_message)
+    message3_nolog (m);
   UNGCPRO;
 }
 
@@ -30430,6 +30430,11 @@ syms_of_xdisp (void)
 
   DEFSYM (Qredisplay_internal, "redisplay_internal (C function)");
 
+  DEFVAR_BOOL("inhibit-message", inhibit_message,
+              doc:  /* Non-nil means calls to `message' are not displayed.
+They are still logged to the *Messages* buffer.  */);
+  inhibit_message = 0;
+
   message_dolog_marker1 = Fmake_marker ();
   staticpro (&message_dolog_marker1);
   message_dolog_marker2 = Fmake_marker ();
-- 
1.8.4

============================================================

Re: Is there a way to inhibit message3 from Elisp?

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 22 Apr 2015 14:50:49 +0200
> 
> Thanks for the comments, Eli. I attach a squashed patch.
> Please check again if it's alright.

Only one gotcha this time:

> +When @code{inhibit-message} is non-nil, no message will be displayed

Take "nil" in @code, since it's a symbol.

Otherwise, looks good to me.  Thanks.

Re: Is there a way to inhibit message3 from Elisp?

[Stefan Monnier]

> I think it's OK, with a few minor comments:

>   +** New variable `inhibit-message', when bound to t, inhibits the

No, as I said I want a variable to *redirect* not to inhibit,


        Stefan

Re: Is there a way to inhibit message3 from Elisp?

[Oleh Krehel]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I think it's OK, with a few minor comments:
>
>>   +** New variable `inhibit-message', when bound to t, inhibits the
>
> No, as I said I want a variable to *redirect* not to inhibit,

Sorry, but I have no idea how to make that work.
The current update fixes my problem though.

Oleh

Re: Is there a way to inhibit message3 from Elisp?

[Artur Malabarba]

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

On Apr 22, 2015 3:51 PM, "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:
>
> > I think it's OK, with a few minor comments:
>
> >   +** New variable `inhibit-message', when bound to t, inhibits the
>
> No, as I said I want a variable to *redirect* not to inhibit,

I think that's independent of this. Which buffer the messages are stored in
is unrelated to whether they get displayed on the echo area.

[-- Attachment #2: Type: text/html, Size: 582 bytes --]

Re: Is there a way to inhibit message3 from Elisp?

[Stefan Monnier]

> I think that's independent of this. Which buffer the messages are stored in
> is unrelated to whether they get displayed on the echo area.

It's not independent: redirecting to the moral equivalent of /dev/null
means that what I want is a superset of what this offers.


        Stefan

Re: Is there a way to inhibit message3 from Elisp?

[Artur Malabarba]

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

On Apr 22, 2015 1:55 PM, "Oleh Krehel" <ohwoeowho@gmail.com> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
> >> I got this code to work as I expect:
> >>
> >> (progn
> >>   (setq inhibit-message t)
> >>   (message "foo")
> >>   (setq inhibit-message nil))
> >>
> >> However, this doesn't work:
> >>
> >> (let ((inhibit-message t))
> >>   (message "foo"))
> >
> > How does it "not work"?  It did for me.
>
> I misunderstood that when "C-x C-e" would not print the message in
> *scratch*. But otherwise, it works.

C-x C-e does print the message. You just don't see it because it
immediately prints the return values afterwards. :-)

[-- Attachment #2: Type: text/html, Size: 1051 bytes --]

Re: Is there a way to inhibit message3 from Elisp?

[Artur Malabarba]

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

> Updated etc/NEWS and the manual (entry for `message').
> Let me know if it's OK to merge.

Now that I think about it, the really ideal way to do this would be to have
a with-no-messages macro/special form, so that stupid packages can't setq
this variable permanently.

But if that's too impractical, the current version is fine.

[-- Attachment #2: Type: text/html, Size: 413 bytes --]

Re: Is there a way to inhibit message3 from Elisp?

[Oleh Krehel]

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

>> Updated etc/NEWS and the manual (entry for `message').
>> Let me know if it's OK to merge.
>
> Now that I think about it, the really ideal way to do this would be to
> have a with-no-messages macro/special form, so that stupid packages
> can't setq this variable permanently. 
>
> But if that's too impractical, the current version is fine.

I'm not sure if it's possible or practical.  message3 is in C, so there
would need to be an Elisp variable that connects the macro and the C
code.

In any case, there's already a good way to deal with stupid packages.

Oleh

Re: Is there a way to inhibit message3 from Elisp?

[Stefan Monnier]

>> desired in general.  It's OK to emit such a message if call-process ends
>> up waiting a non-negligible amount of time for the subprocess to die
>> (so as to explain to the user why Emacs is not responding), but for the
>> usual case where wait_for_termination returns quickly, we should not
>> emit any message at all.
>> Patch welcome to fix this problem.
> Please check the scratch/inhibit-message3 branch.

It's easier if you include the patch in your email messages.

And this patch doesn't seem to address the problem you quoted.


        Stefan