bug#23129: 25.1.50; Prefix key is not echoed during minibuffer completion

[Drew Adams]

> > 0. emacs -Q
> >
> > 1.
> > (defvar bar-map nil)
> > (define-prefix-command 'bar-map)
> > (define-key minibuffer-local-must-match-map "\M-i" 'bar-map)
> > (define-key bar-map "\M-z" 'foo)
> > (defun foo () (interactive) (message "FOOOOOOOOOOO") (sleep-for 2))
> >
> > `M-x M-i'
> > Wait a second.  The prefix key `M-i' is NOT echoed.
> > `M-z'
> > The message from `foo' is shown.
> >
> > 2.
> > (global-set-key "\M-l" 'bar-map)
> >
> > `M-l'
> > Wait a second.  The prefix key `M-l' IS echoed.
> > `M-z'
> > The message from `foo' is shown.
> 
> Is it really necessary to use this complex setup?

Complicated?  It is intended to be clear and sufficient.
Can you not reproduce the problem using that recipe?

If you think the same bug can be repro'd another way, fine.

> Does the following simple recipe exhibit the same behavior?
> (If not, please tell why not.)
> 
>   emacs -Q
>   C-x C-f C-x
> 
> "C-x C-f" causes the prompt showing the current directory; typing
> "C-x" afterwards has no visible effect, whereas you expect it to echo
> the usual "C-x-".  Right?

Is `C-x' a prefix key in `minibuffer-local-filename-completion-map'
at that point?  Yes, but not directly.  So this is not quite the
same as what I reported.  But if you think it adequate to show the
problem, fine.

But consider also this:

M-x C-(

You see the message "C-( is undefined" for a second or so.
`minibuffer-message' is presumably used to show this message.

This shows Emacs's intention to provide help to users by echoing
stuff even when the minibuffer is active.  There is nothing odd
about this.  It is helpful, not harmful.

> > BUG: The prefix key `M-i' should be echoed during completion.
> 
> How do you mean "should"?

How do I mean "should"?  Should.  It is helpful for a user
(as well as consistent) to echo the prefix keys s?he hits.

> AFAICT, this is a deliberate feature:

Do you have evidence for that?  If so, I'll argue that that
is a misfeature (design bug).  If not, I'll argue that it is
an oversight (implementation bug).

I suspect it is an oversight, but I could be wrong.

> we only echo the prefix keys when there's nothing in the
> minibuffer (more accurately, when the minibuffer level of
> recursion is zero).

That's the bug.  Whether deliberate or by accident, it is not
helpful behavior.

We echo lots of things when the minibuffer is active.  That's
what we have `minibuffer-message' for.

> I guess this is so to avoid confusing prompts or something
> (Richard, can you comment on this?), but in any case this is
> how Emacs worked since forever.

Yes, I know the bug is longstanding.  And as long as we're
guessing, I guess it is an oversight.

I also know that Emacs itself has so far not bound many keys
in minibuffer keymaps.  But that has changed in the wider Emacs
world.  My guess is that vanilla Emacs never even considered
the use case of prefix keys bound in minibuffer keymaps.

A user hitting a prefix key during minibuffer input has just as
much need to see that echoed as s?he does when hitting a prefix
key at top-level.  I see no reason not to echo it.  It is not
good interaction for users to see nothing happen when they hit
keys, especially if those keys are bound and they do, in fact,
have an (unreported) effect.


[FWIW, in Icicles I echo prefix arguments (e.g. `C-u', `M-7')
used during minibuffer input.  And you can apply a prefix arg to
individual candidates.  Without such echoing, this interaction
would be less helpful and more confusing than it needs to be.
I haven't seen (or really looked for) a way to echo prefix keys
as well, or else I would have done that also.]