I do lots of automatizing in Emacs, by stacking commands that I know from using manually. That is a method I recommend, because it doesn't take much effort: you use Emacs as you ordinarily would, and now and then it pops to your head, "hey, I'm always using those commands in succession, why don't I just merge them?" All the more simple since you know the commands, by name or shortcut.

One problem, though, is that when you stack commands, you get lots of messages flashing by in the "echo area" (same place as the minibuffer). Those messages don't make any sense, as everything going on below (the functions invoked) is (should be) transparent to the user.

So, could you mute it, and then unmute it? Take a look below:

(defun invisible-pretty-mail ()
  "Automatize `pretty-mail'."
  ; (mute-echo-area)
  (pretty-mail) ; lots of replace-string, replace-regexp, etc. here
                ; that will flood messages
  ; (unmute-echo-area)

Edit in response to sds' answer:

I'm very much aware of those notes you refer to, as they are very common in the Emacs help system.

While your advice is not incorrect in general, let us examine this particular situation in greater detail: 1) There is an Elisp function in .emacs. 2) It uses commands that the person who setup the function is very familiar with, so it is very readable and maintainable. 3) The function works exactly as intended, with 4) the one drawback that it echos too many messages.

Now, in this situation, would you really suggest a complete rewrite of that function (and many others), using altogether different commands, commands that may or may not exist, as a possible way of reducing messages, which we won't even know will happen?

Edit: An example (that works), after the help I got from Drew.

(defun test-suppress-msgs ()
  (let ((log-size message-log-max))
    (setq message-log-max nil)
    (message "This message is suppressed.")
    (setq message-log-max log-size)
    (message "This is echoed, and logged.") ))
  • I think this should be on stackoverflow, not here – sds Mar 7 '13 at 13:15
  • @sds: No, were are allowed to speak about software that is used on Unix and/or GNU/Linux systems. And, although this is a problem solvable by programming (as most computer problems are :), Elisp is specific to Emacs, which is a Un*x/GNU application if there ever was one. – Emanuel Berg Mar 7 '13 at 20:33

Binding message-log-max to nil suppresses messages for the duration of the (dynamic) binding.

Binding echo-keystrokes to 0 suppresses echoing of keystrokes.

Starting with Emacs 25.1, you can also bind (or set) variable inhibit-message to non-nil, to prevent most echo-area messages (but not prevent those messages from being logged in buffer *Messages*).

  • 2
    Now there also is inibit-message that can be set to t. – Joelmob Feb 3 '17 at 13:12
  • @Joelmob: Noted. But most Emacs users do not use the latest release... – Drew Feb 3 '17 at 21:43

I don't see anything which could do what you want in the Emacs source code.

Note that your method "stacking commands that I know from using manually" is not necessarily TRT. Quite a few Emacs commands are deprecated as a part of lisp code, e.g.,

C-x b runs the command switch-to-buffer
WARNING: This is NOT the way to work on another buffer temporarily
within a Lisp program!


previous-line is an interactive compiled Lisp function in `simple.el'.
It is bound to C-p, <up>.
If you are thinking of using this in a Lisp program, consider using
`forward-line' with a negative argument instead.  It is usually easier
to use and more reliable (no dependence on goal column, etc.).

I.e., when writing Lisp code, it is best to use primitives instead of interactive commands, this should also reduce the message stream you are concerned with.


More importantly, this will make your functions more robust - they will depend less on various settings, and they will be less likely to suddenly break when you decide to try out a new user option.

I understand that this is not what you are asking, and I say it right away that, IMO, there is no way to suppress the messages.

  • Check out the question; made an edit that was too long to post as a comment. – Emanuel Berg Mar 7 '13 at 20:23
  • @EmanuelBerg: edited the answer – sds Mar 7 '13 at 20:30
  • OK, robustness is a better argument, but not good enough in my situation where I have tons of such functions and have had no such problems thus far. But yes, that's a good point. – Emanuel Berg Mar 7 '13 at 20:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.