GNU bug report logs - #31855
27.0.50; Async shell command finished message not visible any more

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Sat, 16 Jun 2018 05:14:01 UTC

Severity: normal

Merged with 31860

Found in version 27.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 31855 <at> debbugs.gnu.org
Subject: bug#31855: 27.0.50; Async shell command finished message not visible any more
Date: Sat, 16 Jun 2018 14:17:22 -0700
On 06/16/2018 01:48 AM, Eli Zaretskii wrote:
>> From: Michael Heerdegen <michael_heerdegen <at> web.de>
>> Date: Sat, 16 Jun 2018 07:12:50 +0200
>>
>> In emacs25 -Q, I type, for example, M-! t r u e SPC & <return>, and the
>> echo area displays "true: finished".
>>
>> In master emacs -Q, doing the same gives you no visible feedback any
>> more.  A message is logged in *Messages*, but it seems to be dismissed
>> immediately.
> 
> Daniel, this seems to be due to your recent changes in keyboard.c.  If
> I make the change below, which reverts a small part of your changes,
> the problem is gone:
> 
> diff --git a/src/keyboard.c b/src/keyboard.c
> index 5409918..76097e8 100644
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -8999,7 +8999,7 @@ read_key_sequence (Lisp_Object *keybuf, Lisp_Object prompt,
>     /* These are no-ops the first time through, but if we restart, they
>        revert the echo area and this_command_keys to their original state.  */
>     this_command_key_count = keys_start;
> -  if (INTERACTIVE && is_replay)
> +  if (INTERACTIVE && t < mock_input)
>       echo_truncate (echo_start);
>     is_replay = true;

Yep. You're right. I'll bring us back to the old logic here.

I just worry that the "t < mock_input" condition is wrong in the case 
where we use a function key map to rewrite an input to nothing, but 
maybe the improved last_nonmenu_event tracking will fix that class of 
problem by itself.




This bug report was last modified 7 years and 33 days ago.

Previous Next


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