Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!USWEST.COM!jbw
From: jbw@USWEST.COM (Joe Wells)
Newsgroups: gnu.emacs.bug
Subject: bug in minibuffer-complete
Message-ID: <8907192045.AA01288@ketchum.uswest.com>
Date: 19 Jul 89 20:45:26 GMT
References: <8907191913.AA00889@ew09.nas.nasa.gov>
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 26

Eric L. Raible writes:
 >    From: Joe Wells <jbw@uswest.com>
 >    Not really a bug, more of a subtle interation problem.  When you use
 >    message, the contents of the message are displayed instead of the contents
 >    of the minibuffer.  The "[no match]" message is implemented by modifying
 >    the contents of the minibuffer temporarily.  In your case, by the time the
 >    message stops being displayed, the minibuffer contents have been restored,
 >    so you don't see the "[no match]".  If you wanted, you could modify the
 >    function that displays the "[no match]" and make it clear out the message
 >    buffer so that the minibuffer contents are displayed.  (That by itself is
 >    quite a trick from lisp, took me a long time to figure out.)
 > 
 > You might call this a "subtle interation problem", but I call it a
 > subtle bug.
 > 
 > Regardless of the reasons behind it, this is undesirable behavior.

Not true.  The problem is that your function is calling message.  At this
point, the completion code has two choices, to display the "[no match]"
message and trash your message, or to allow the message to take
precedence.  Without knowing how important the message is or for how long
it has been displayed, it is unwise to destroy the message.

--
Joe Wells <jbw@uswest.com>
jbw%ketchum.uswest.com@boulder.colorado.edu