Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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'."
  (interactive)
  ; (mute-echo-area)
  (rmail-edit-current-message)
  (pretty-mail) ; lots of replace-string, replace-regexp, etc. here
                ; that will flood messages
  (rmail-cease-edit)
  ; (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 ()
  (interactive)
  (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.") ))
share|improve this question
    
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

2 Answers 2

up vote 2 down vote accepted
+50

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

Binding echo-keystrokes to 0 suppresses echoing of keystrokes.

share|improve this answer

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!

and

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.

Edit:

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.

share|improve this answer
    
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

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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