bug#46243: [External] : Re: bug#46243: 26.3; If invoke menu item that reads a char, get keystrokes echo

[Stefan Monnier]

> This is a consequence of fixing bug#15332.  CC'ing Stefan, who both
> reported the bug and installed the fix.
> Stefan, the change you made to fix that bug, viz.:
>
> diff --git a/src/keyboard.c b/src/keyboard.c
> index 440820c..020c885 100644
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -2596,10 +2596,8 @@ read_char (int commandflag, Lisp_Object map,
>  
>    if (/* There currently is something in the echo area.  */
>        !NILP (echo_area_buffer[0])
> -      && (/* And it's either not from echoing.  */
> -       !EQ (echo_area_buffer[0], echo_message_buffer)
> -       /* Or it's an echo from a different kboard.  */
> -       || echo_kboard != current_kboard
> +      && (/* It's an echo from a different kboard.  */
> +       echo_kboard != current_kboard
>         /* Or we explicitly allow overwriting whatever there is.  */
>         || ok_to_echo_at_next_pause == NULL))
>      cancel_echoing ();
>    else
>      echo_dash ();
>
> is what's causing this one: where we previously called cancel_echoing,
> because !EQ (echo_area_buffer[0], echo_message_buffer) was true, we
> now call echo_dash, because the remaining 2 conditions are false.
>
> The change you installed is not explained, so I cannot reason about
> the importance of echo_message_buffer.  Do you remember why you
> decided to remove that 3rd condition?

I don't think I understood the echo-keystrokes code very back then and
I still don't understand it very much either.

This fixed the problem, but I'm not sure why.  I just tried to revert
this change and it does re-introduce part of the problem mentioned in
bug#15332:

    C-u [..wait..] 5

gives me immediately `C-u 5-` in the echo area whereas

    C-u [..wait..] 5 5

only shows `C-u 55-` after the `echo-keystrokes` delay.


        Stefan