Re: messages override minibuffer input

["Davis Herring" <herring@lanl.gov>]

> I am always annoyed when emacs is waiting for input in the
> minibuffer, and in the meanwhile an (idle-) timer function kicks in,
> producing a message that overrides the content displayed in the
> minibuffer. I was once told that timer functions should be designed
> such that they do not produce any output. I do not know whether this
> is always a good strategy. On the other hand, I do not know how many
> (too many?) packages violate such a strategy. (Probably, it would
> help if the elisp manual gave a recommendation concerning the usage
> of noisy functions inside timer functions.)

When I have written timers that produced output, it has been
"informational" output which is not critical to see; then I have merely
skipped printing unless the echo area either is empty or contains my
timer's previous output, and the minibuffer is not active.  Would this be
a good general function to provide?  (What follows is not tested; I don't
have known-working code to hand.)

(defvar optional-message nil
  "The last message shown with the function `optional-message'.")
(defun optional-message (fmt &rest args)
  "Display a message if there's nothing better being displayed."
  (or (active-minibuffer-window)
      (not (eq (current-message) optional-message))
      (message "%s" (setq optional-message (apply 'format fmt args)))))

I suppose some provision could be made for putting the message into
*Messages* even if it's not displayed, but I'm not sure what the best way
to do that is.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.