Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!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: <8907191806.AA01267@ketchum.uswest.com>
Date: 19 Jul 89 18:06:18 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 30

Eric L. Raible writes:
 > The [no match] message from minibuffer-complete does not get displayed
 > in some circumstances.
 > 
 > This seems to be an old bug.  I verified it on two different
 > machines (BSD VAX and SGI 4D) in versions 18.50, 18.52, 18.54, 18.55.
 > 
 > Execute illustrate-no-match-bug for a demonstration.
 > 
 [stuff deleted]
 > 
 > (defun test ()
 >   (interactive)
 >   (if (eq last-command-char ?a)
 >       (message "We get the beep.  Where is the [no match] message??? "))
 >   (minibuffer-complete))

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.)

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