bug#12682: 24.2.50; make server-execute less noisy

bug#12682: 24.2.50; make server-execute less noisy

[Christopher Schmidt]

severity: wishlist

In server-execute, there is this form:

    (message "%s" (substitute-command-keys
                   "When done with this frame, type \\[delete-frame]"))

It would be great if one could disable this messages.

        Christopher

bug#12682: 24.2.50; make server-execute less noisy

[Glenn Morris]

Christopher Schmidt wrote:

> In server-execute, there is this form:
>
>     (message "%s" (substitute-command-keys
>                    "When done with this frame, type \\[delete-frame]"))
>
> It would be great if one could disable this messages.

Maybe it could respect emacsclient's --quiet option?

bug#12682: 24.2.50; make server-execute less noisy

[Juanma Barranquero]

On Fri, Oct 19, 2012 at 6:46 PM, Glenn Morris <rgm@gnu.org> wrote:

> Maybe it could respect emacsclient's --quiet option?

I don't think it's a good match. And Christopher likely wants to
silence the message in all situations.

The fact is that many Emacs functions show messages and we don't add
options to disable them. In this case it is trivial to add an advice
in his own's .emacs:

 (defadvice server-execute (around silence-server-execute activate compile)
   (with-temp-message ""
     ad-do-it))

and the messages still get logged on *Messages* in case there's
something else going on (or the advice can be more sofisticate and
check *Messages* to be sure than nothing untold is happening).

This is a wontfix IMO.

    Juanma

bug#12682: 24.2.50; make server-execute less noisy

[Christopher Schmidt]

Juanma Barranquero <lekktu@gmail.com> writes:
> On Fri, Oct 19, 2012 at 6:46 PM, Glenn Morris <rgm@gnu.org> wrote:
>
>> Maybe it could respect emacsclient's --quiet option?
>
> I don't think it's a good match. And Christopher likely wants to
> silence the message in all situations.
>
> The fact is that many Emacs functions show messages and we don't add
> options to disable them. In this case it is trivial to add an advice
> in his own's .emacs:
>
>  (defadvice server-execute (around silence-server-execute activate compile)
>    (with-temp-message ""
>      ad-do-it))
>
> and the messages still get logged on *Messages* in case there's
> something else going on (or the advice can be more sofisticate and
> check *Messages* to be sure than nothing untold is happening).

There are other, useful messages in server-execute.  A more
sophisticated advice is not trivial any more.  server-execute is an
internal, undocumented function.  The message may be subject to change,
the form might be refactored to another function in future versions.  I
would like to have a permanent solution.

There are many superfluous messages floating around, making my
*Messages*-buffer a pain to look at and my minibuffer a constant source
of distraction.  I will not create feature requests for all these
messages.  Right now, to me, it is just about this one and the one I
reported in bug 12370 because IMO these two provide absolutely no value
whatsoever.  I am fine with "Mark set", "Starting new Ispell process",
"Quit", etc. - but Emacs telling me the keys of its most fundamental
commands - all the time, all over again!?  I do not like that.

Having that said...

> This is a wontfix IMO.

...I am fine with wontfix.

I guess a real solution to the underlying problem would be to attach a
log-level or a category-symbol to each message, with the user being able
to disable certain categories.  I do realise this is quiet a demand and
there are lots of more important things to implement.

        Christopher

bug#12682: 24.2.50; make server-execute less noisy

[Juanma Barranquero]

On Sun, Oct 21, 2012 at 9:55 PM, Christopher Schmidt
<christopher@ch.ristopher.com> wrote:

> There are other, useful messages in server-execute.  A more
> sophisticated advice is not trivial any more.

Not very hard, anyway.

> server-execute is an
> internal, undocumented function.  The message may be subject to change,
> the form might be refactored to another function in future versions.  I
> would like to have a permanent solution.

Fair enough.

> There are many superfluous messages floating around, making my
> *Messages*-buffer a pain to look at and my minibuffer a constant source
> of distraction.  I will not create feature requests for all these
> messages.  Right now, to me, it is just about this one and the one I
> reported in bug 12370 because IMO these two provide absolutely no value
> whatsoever.

I suppose "superfluous" is in the eye of the beholder. I find the C-x
# message a useful reminder (because I really rarely use emacsclient
without --no-wait), and it seems like a newbie-oriented message
anyway.

> ...I am fine with wontfix.

I haven't tagged it as wontfix, just stating my opinion. Someone is
bound to differ, I suppose.

> I guess a real solution to the underlying problem would be to attach a
> log-level or a category-symbol to each message, with the user being able
> to disable certain categories.  I do realise this is quiet a demand and
> there are lots of more important things to implement.

I think both messages and warnings should have a customizable way to
filter them out (with several criteria, from the very text of the
message/warning to categories, etc). For warnings that already exists
through the severity level, though it is pretty coarse.

    Juanma

bug#12682: 24.2.50; make server-execute less noisy

[Lars Ingebrigtsen]

Juanma Barranquero <lekktu@gmail.com> writes:

> The fact is that many Emacs functions show messages and we don't add
> options to disable them. In this case it is trivial to add an advice
> in his own's .emacs:
>
>  (defadvice server-execute (around silence-server-execute activate compile)
>    (with-temp-message ""
>      ad-do-it))

We now have `set-message-function', which can be used by the user to
filter out messages that the user doesn't like.

> and the messages still get logged on *Messages* in case there's
> something else going on (or the advice can be more sofisticate and
> check *Messages* to be sure than nothing untold is happening).
>
> This is a wontfix IMO.

So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no