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

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.

BUG: The prefix key `M-i' should be echoed during completion.


In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
 of 2015-12-10
Repository revision: 6148555ee5a3d0139ae517803718b3e0357933c7
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --prefix=/c/Devel/emacs/snapshot/trunk --enable-checking=yes
 --enable-check-lisp-object-type --without-compress-install 'CFLAGS=-Og
 -ggdb3' LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

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

[Eli Zaretskii]

> Date: Sun, 27 Mar 2016 15:34:02 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> 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?  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?

> BUG: The prefix key `M-i' should be echoed during completion.

How do you mean "should"?  AFAICT, this is a deliberate feature: we
only echo the prefix keys when there's nothing in the minibuffer (more
accurately, when the minibuffer level of recursion is zero).  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.

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

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

[Eli Zaretskii]

> Date: Mon, 28 Mar 2016 09:00:35 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 23129@debbugs.gnu.org
> 
> > 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?

What's the significance of minibuffer-local-filename-completion-map
for the purposes of this issue?

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

There's also "should" as in "it did this yesterday or the last year".

> > AFAICT, this is a deliberate feature:
> 
> Do you have evidence for that?

I've read the code.  It does this explicitly and purposefully, there's
no mistake about that.

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

We are not guessing, see below.  The function echo_now is the one that
echoes the prefix keys; look at the conditions (and the commentary,
for that matter).

I hope Richard will be able to shed some light on this.  The code is
very old, it was present in the initial commit in Jan 1992:


  /* If in middle of key sequence and minibuffer not active,
                                      ^^^^^^^^^^^^^^^^^^^^^
     start echoing if enough time elapses.  */

  if (minibuf_level == 0   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
      && !end_time
      && !current_kboard->immediate_echo
      && (this_command_key_count > 0
	  || !NILP (call0 (Qinternal_echo_keystrokes_prefix)))
      && ! noninteractive
      && echo_keystrokes_p ()
      && (/* No message.  */
	  NILP (echo_area_buffer[0])
	  /* Or empty message.  */
	  || (BUF_BEG (XBUFFER (echo_area_buffer[0]))
	      == BUF_Z (XBUFFER (echo_area_buffer[0])))
	  /* Or already echoing from same kboard.  */
	  || (echo_kboard && ok_to_echo_at_next_pause == echo_kboard)
	  /* Or not echoing before and echoing allowed.  */
	  || (!echo_kboard && ok_to_echo_at_next_pause)))
    {
      /* After a mouse event, start echoing right away.
	 This is because we are probably about to display a menu,
	 and we don't want to delay before doing so.  */
      if (EVENT_HAS_PARAMETERS (prev_event))
	echo_now ();
      else
	{
	  Lisp_Object tem0;

	  save_getcjmp (save_jump);
	  restore_getcjmp (local_getcjmp);
	  tem0 = sit_for (Vecho_keystrokes, 1, 1);
	  restore_getcjmp (save_jump);
	  if (EQ (tem0, Qt)
	      && ! CONSP (Vunread_command_events))
	    echo_now ();
	}
    }

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

[Drew Adams]

> > Is `C-x' a prefix key in `minibuffer-local-filename-completion-map'
> > at that point?
> 
> What's the significance of minibuffer-local-filename-completion-map
> for the purposes of this issue?

The use case is a prefix-key binding in a minibuffer keymap.
That is, a key that is specifically useful in the context of
minibuffer input.

The bug is not echoing a prefix key for an active minibuffer.
Yes, any prefix key in any accessible keymap will do, to show
the problem.  But the really useful use cases are prefix keys
bound in a minibuffer keymap.

> > > 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.
> 
> There's also "should" as in "it did this yesterday or the last
> year".

OK.  (If that were the case then I would have said that this
was a regression.)  Anyway, it's now clear what I meant by
"should", hopefully.

> > > AFAICT, this is a deliberate feature:
> >
> > Do you have evidence for that?
> 
> I've read the code.  It does this explicitly and purposefully,
> there's no mistake about that.

Fair enough.  But just because someone codes something in a
particular way, that does not say anything, by itself, about
how much thought or user experience went into the design that
it reflects (or creates).

As I said, if this was by design then this is a design-bug
report.  The design is flawed/weak and can be improved in
this regard.

Using prefix keys in the minibuffer might not have been
considered a great deal when this was implemented, even
if the implementation shows that excluding their echo was
deliberate.

Prefix keys certainly are allowed to be used, even if users
do not benefit from their being echoed.

> The function echo_now is the one that echoes the prefix keys;
> look at the conditions (and the commentary, for that matter).
> 
> I hope Richard will be able to shed some light on this.  The code
> is very old, it was present in the initial commit in Jan 1992:
> 
>   /* If in middle of key sequence and minibuffer not active,
>                                       ^^^^^^^^^^^^^^^^^^^^^
>   if (minibuf_level == 0   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<

OK, it was intentionally coded this way - it was not a coding
oversight.  It was a design oversight.  I see no good reason
for the design to exclude the minibuffer case for echoing.
Do you?  Maybe Richard will provide a good argument.

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

[Drew Adams]

Having just noticed the merge message for bugs 22825 and
23240, and looking at the bug descriptions, it seems to me
that both of them are essentially the same bug as this one,
23129, although this one is echoing during minibuffer input
and that one is about input during key reading.  (That one
is not about just `C-h c'.) 

And really the problem is more general than either of these
bug descriptions.  It is not just about prefix-key echoing
being dropped during minibuffer completion.  And it is not
just about it being dropped during key reading.

It is about prefix-key echoing being dropped when expecting
some input from the user.  The user has hit a prefix key
and that is not getting echoed.  The user gets no feedback.

I recognize that minibuffer reading of input is different,
in terms of implementation, from key reading (reading an
event).  But the user need is the same in these cases:
a prefix key should be echoed, so the user knows what
key s?he hit and knows what Emacs understood and expects.

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

[Eli Zaretskii]

> Date: Fri, 8 Apr 2016 08:56:09 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: rms@gnu.org, 23129@debbugs.gnu.org
> 
> Having just noticed the merge message for bugs 22825 and
> 23240, and looking at the bug descriptions, it seems to me
> that both of them are essentially the same bug as this one,
> 23129, although this one is echoing during minibuffer input
> and that one is about input during key reading.  (That one
> is not about just `C-h c'.) 

No, those two are different, and already fixed in the repository.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I've read the code.  It does this explicitly and purposefully, there's
> no mistake about that.

And I don't think we want to change the behaviour here -- it would be
pretty confusing.  So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no