* Is there a way to inhibit message3 from Elisp?
@ 2015-04-21 13:37 Oleh Krehel
2015-04-21 17:17 ` Stefan Monnier
0 siblings, 1 reply; 18+ messages in thread
From: Oleh Krehel @ 2015-04-21 13:37 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-21 13:37 Is there a way to inhibit message3 from Elisp? Oleh Krehel
@ 2015-04-21 17:17 ` Stefan Monnier
2015-04-21 18:50 ` Oleh Krehel
0 siblings, 1 reply; 18+ messages in thread
From: Stefan Monnier @ 2015-04-21 17:17 UTC (permalink / raw
To: Oleh Krehel; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-21 17:17 ` Stefan Monnier
@ 2015-04-21 18:50 ` Oleh Krehel
2015-04-21 23:25 ` Artur Malabarba
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Oleh Krehel @ 2015-04-21 18:50 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-21 18:50 ` Oleh Krehel
@ 2015-04-21 23:25 ` Artur Malabarba
2015-04-22 6:00 ` Oleh Krehel
2015-04-22 10:53 ` Eli Zaretskii
2015-04-22 13:53 ` Stefan Monnier
2 siblings, 1 reply; 18+ messages in thread
From: Artur Malabarba @ 2015-04-21 23:25 UTC (permalink / raw
To: Oleh Krehel; +Cc: Stefan Monnier, emacs-devel
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
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-21 23:25 ` Artur Malabarba
@ 2015-04-22 6:00 ` Oleh Krehel
0 siblings, 0 replies; 18+ messages in thread
From: Oleh Krehel @ 2015-04-22 6:00 UTC (permalink / raw
To: Artur Malabarba; +Cc: Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-21 18:50 ` Oleh Krehel
2015-04-21 23:25 ` Artur Malabarba
@ 2015-04-22 10:53 ` Eli Zaretskii
2015-04-22 11:55 ` Oleh Krehel
2015-04-22 13:53 ` Stefan Monnier
2 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2015-04-22 10:53 UTC (permalink / raw
To: Oleh Krehel; +Cc: monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-22 10:53 ` Eli Zaretskii
@ 2015-04-22 11:55 ` Oleh Krehel
2015-04-22 12:24 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Oleh Krehel @ 2015-04-22 11:55 UTC (permalink / raw
To: Eli Zaretskii; +Cc: monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-22 11:55 ` Oleh Krehel
@ 2015-04-22 12:24 ` Eli Zaretskii
2015-04-22 12:50 ` Oleh Krehel
2015-04-22 13:51 ` Stefan Monnier
2015-04-22 12:42 ` Artur Malabarba
2015-04-22 17:22 ` Artur Malabarba
2 siblings, 2 replies; 18+ messages in thread
From: Eli Zaretskii @ 2015-04-22 12:24 UTC (permalink / raw
To: Oleh Krehel; +Cc: monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-22 11:55 ` Oleh Krehel
2015-04-22 12:24 ` Eli Zaretskii
@ 2015-04-22 12:42 ` Artur Malabarba
2015-04-22 17:22 ` Artur Malabarba
2 siblings, 0 replies; 18+ messages in thread
From: Artur Malabarba @ 2015-04-22 12:42 UTC (permalink / raw
To: Oleh; +Cc: Eli Zaretskii, Stefan Monnier, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-22 12:24 ` Eli Zaretskii
@ 2015-04-22 12:50 ` Oleh Krehel
2015-04-22 13:01 ` Eli Zaretskii
2015-04-22 13:51 ` Stefan Monnier
1 sibling, 1 reply; 18+ messages in thread
From: Oleh Krehel @ 2015-04-22 12:50 UTC (permalink / raw
To: Eli Zaretskii; +Cc: monnier, emacs-devel
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
============================================================
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-22 12:50 ` Oleh Krehel
@ 2015-04-22 13:01 ` Eli Zaretskii
0 siblings, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2015-04-22 13:01 UTC (permalink / raw
To: Oleh Krehel; +Cc: monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-22 13:51 ` Stefan Monnier
@ 2015-04-22 13:48 ` Oleh Krehel
2015-04-22 17:39 ` Artur Malabarba
1 sibling, 0 replies; 18+ messages in thread
From: Oleh Krehel @ 2015-04-22 13:48 UTC (permalink / raw
To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-22 12:24 ` Eli Zaretskii
2015-04-22 12:50 ` Oleh Krehel
@ 2015-04-22 13:51 ` Stefan Monnier
2015-04-22 13:48 ` Oleh Krehel
2015-04-22 17:39 ` Artur Malabarba
1 sibling, 2 replies; 18+ messages in thread
From: Stefan Monnier @ 2015-04-22 13:51 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Oleh Krehel, emacs-devel
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-21 18:50 ` Oleh Krehel
2015-04-21 23:25 ` Artur Malabarba
2015-04-22 10:53 ` Eli Zaretskii
@ 2015-04-22 13:53 ` Stefan Monnier
2 siblings, 0 replies; 18+ messages in thread
From: Stefan Monnier @ 2015-04-22 13:53 UTC (permalink / raw
To: Oleh Krehel; +Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-22 17:22 ` Artur Malabarba
@ 2015-04-22 17:20 ` Oleh Krehel
0 siblings, 0 replies; 18+ messages in thread
From: Oleh Krehel @ 2015-04-22 17:20 UTC (permalink / raw
To: Artur Malabarba; +Cc: Eli Zaretskii, Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-22 11:55 ` Oleh Krehel
2015-04-22 12:24 ` Eli Zaretskii
2015-04-22 12:42 ` Artur Malabarba
@ 2015-04-22 17:22 ` Artur Malabarba
2015-04-22 17:20 ` Oleh Krehel
2 siblings, 1 reply; 18+ messages in thread
From: Artur Malabarba @ 2015-04-22 17:22 UTC (permalink / raw
To: Oleh; +Cc: Eli Zaretskii, Stefan Monnier, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-22 13:51 ` Stefan Monnier
2015-04-22 13:48 ` Oleh Krehel
@ 2015-04-22 17:39 ` Artur Malabarba
2015-04-22 20:20 ` Stefan Monnier
1 sibling, 1 reply; 18+ messages in thread
From: Artur Malabarba @ 2015-04-22 17:39 UTC (permalink / raw
To: Stefan Monnier; +Cc: Eli Zaretskii, Oleh, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Is there a way to inhibit message3 from Elisp?
2015-04-22 17:39 ` Artur Malabarba
@ 2015-04-22 20:20 ` Stefan Monnier
0 siblings, 0 replies; 18+ messages in thread
From: Stefan Monnier @ 2015-04-22 20:20 UTC (permalink / raw
To: Artur Malabarba; +Cc: Eli Zaretskii, Oleh, emacs-devel
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2015-04-22 20:20 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-21 13:37 Is there a way to inhibit message3 from Elisp? Oleh Krehel
2015-04-21 17:17 ` Stefan Monnier
2015-04-21 18:50 ` Oleh Krehel
2015-04-21 23:25 ` Artur Malabarba
2015-04-22 6:00 ` Oleh Krehel
2015-04-22 10:53 ` Eli Zaretskii
2015-04-22 11:55 ` Oleh Krehel
2015-04-22 12:24 ` Eli Zaretskii
2015-04-22 12:50 ` Oleh Krehel
2015-04-22 13:01 ` Eli Zaretskii
2015-04-22 13:51 ` Stefan Monnier
2015-04-22 13:48 ` Oleh Krehel
2015-04-22 17:39 ` Artur Malabarba
2015-04-22 20:20 ` Stefan Monnier
2015-04-22 12:42 ` Artur Malabarba
2015-04-22 17:22 ` Artur Malabarba
2015-04-22 17:20 ` Oleh Krehel
2015-04-22 13:53 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.