GNU bug report logs - #23129
25.1.50; Prefix key is not echoed during minibuffer completion

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Sun, 27 Mar 2016 22:35:01 UTC

Severity: minor

Tags: wontfix

Found in version 25.1.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #14 received at 23129 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: rms <at> gnu.org, 23129 <at> debbugs.gnu.org
Subject: Re: bug#23129: 25.1.50;	Prefix key is not echoed during minibuffer
 completion
Date: Mon, 28 Mar 2016 19:16:33 +0300
> Date: Mon, 28 Mar 2016 09:00:35 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 23129 <at> 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 ();
	}
    }




This bug report was last modified 3 years and 153 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.