minibuffer messages overwritten by the next question too fast

[Dan Jacobson]

Gentlemen, you might have a problem where some messages get covered
over by the next question.  E.g. I did C-x s, and noticed something
flicking by real fast while I was answering y or no to if I wanted to
save each file.  So I checked *Messages*

Wrote /home/jidanni/geocities/map_freedom.html
timestamp delimiter start was not found
Wrote /home/jidanni/geocities/dan-preface.htm

Ah, no wonder, the "not found" warning is covered up right away by the
next question on if I want to save some other file!  There is a
write-hook of html helper mode that wants to put a timestamp on a file
one saves, I think, and whatever it wants to say in the minibuffer
gets covered up right away by the next question.... you could blame a
person for writing things in the minibuffer for not also calling
wait-a-second or whatever, I guess... but who was to know a mack truck
would be coming right up behind...

Maybe it's just like how we were taught to use
echo trouble >&2
never expecting that it might get wiped away if we don't sleep 1.

|message is a built-in function...
|
|If the first argument is nil, clear any existing message; let the
|minibuffer contents show.

This last line of Help seem odd meaning-wise: show? show what? show
show show your boat... :-).  Also one isn't told to add wait-a-second...

Also when I do 
(and(message "xxvv" )(message "ccbdc" ))^X^E
I only see the last message.  Oh, I see, any use of message clears the
existing message.  "" is not anything special, just a very very short message.

[By the way, when I sent this I hit C-c C-c in gnus, which now said C-c
C-c - like it was waiting for a third keystroke but indeed was waiting
for me to confirm that I wanted to resend this, as I had already sent
this buffer once but continued to edit it.  This now happens
occasionally in the current emacs/gnus as seen in my headers... though
I haven't got more to pin it down yet.]

-- 
http://www.geocities.com/jidanni/ Tel+886-4-25854780