raible@EW09.NAS.NASA.GOV (Eric L. Raible) (07/13/89)
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.
(defun illustrate-no-match-bug ()
(interactive)
(let ((minibuffer-completion-table '(())) ; a map which has no matches
(test-map (copy-keymap minibuffer-local-map)))
(define-key test-map "a" 'test)
(define-key test-map "b" 'test)
(read-from-minibuffer "See that 'a' and 'b' have different behavior:"
"" test-map)))
(defun test ()
(interactive)
(if (eq last-command-char ?a)
(message "We get the beep. Where is the [no match] message??? "))
(minibuffer-complete))jbw@USWEST.COM (Joe Wells) (07/20/89)
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
raible@EW09.NAS.NASA.GOV (Eric L. Raible) (07/20/89)
Date: Wed, 19 Jul 89 12:06:18 MDT 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.
jbw@USWEST.COM (Joe Wells) (07/20/89)
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