Echoing of keys and process I/O

Echoing of keys and process I/O

[Daniel Jensen]

When Emacs is communicating with a process, the display of multi-
character keys in the echo area is disturbed. I was wondering why this
is so, and if there is anything that can be done about it.

For example, in shell mode:

    while true; do echo; sleep .5; done

Now I can't see keystrokes in the echo area unless I set
echo-keystrokes to <= 0.5.

Another peculiarity, which is new in Emacs 22 and also apparently
caused by process communication, is that a space is inserted before
the key in the echo area. I can see the text jump to the right.

Re: Echoing of keys and process I/O

[Chong Yidong]

daniel@bigwalter.net (Daniel Jensen) writes:

> When Emacs is communicating with a process, the display of multi-
> character keys in the echo area is disturbed. I was wondering why this
> is so, and if there is anything that can be done about it.
>
> For example, in shell mode:
>
>     while true; do echo; sleep .5; done
>
> Now I can't see keystrokes in the echo area unless I set
> echo-keystrokes to <= 0.5.

I can't reproduce this on

  GNU Emacs 22.0.94.3 (i686-pc-linux-gnu, GTK+ Version 2.10.6)

Using the following recipe (echo-keystrokes == 1):

M-x shell RET
while true; do echo; sleep .5; done RET
C-u 1 C-x

The string "C-u 1 C-x" appears in the echo area.

Re: Echoing of keys and process I/O

[Daniel Jensen]

Chong Yidong <cyd@stupidchicken.com> writes:

> daniel@bigwalter.net (Daniel Jensen) writes:
>
>> When Emacs is communicating with a process, the display of multi-
>> character keys in the echo area is disturbed. I was wondering why this
>> is so, and if there is anything that can be done about it.
>>
>> For example, in shell mode:
>>
>>     while true; do echo; sleep .5; done
>>
>> Now I can't see keystrokes in the echo area unless I set
>> echo-keystrokes to <= 0.5.
>
> I can't reproduce this on
>
>   GNU Emacs 22.0.94.3 (i686-pc-linux-gnu, GTK+ Version 2.10.6)

I have experimented some more with different versions of Emacs,
including one built from the latest CVS sources (i686-pc-linux-gnu),
and I have now found one way to avoid this echo area blocking: All is
well while I'm using Emacs 22 in a virtual terminal.

I still see the bug when I'm in X, even with an Emacs without X
support running in an xterm. It's the same on several GNU/Linux
systems, so I don't think I have misconfigured something.

Re: Echoing of keys and process I/O

[Chong Yidong]

daniel@bigwalter.net (Daniel Jensen) writes:

> I have experimented some more with different versions of Emacs,
> including one built from the latest CVS sources (i686-pc-linux-gnu),
> and I have now found one way to avoid this echo area blocking: All is
> well while I'm using Emacs 22 in a virtual terminal.
>
> I still see the bug when I'm in X, even with an Emacs without X
> support running in an xterm. It's the same on several GNU/Linux
> systems, so I don't think I have misconfigured something.

I don't see the bug when I'm in X, on my GNU/Linux laptop.  If you
could post a detailed recipe, maybe that will help.

Re: Echoing of keys and process I/O

[Daniel Jensen]

Chong Yidong <cyd@stupidchicken.com> writes:

> daniel@bigwalter.net (Daniel Jensen) writes:
>
>> I have experimented some more with different versions of Emacs,
>> including one built from the latest CVS sources (i686-pc-linux-gnu),
>> and I have now found one way to avoid this echo area blocking: All is
>> well while I'm using Emacs 22 in a virtual terminal.
>>
>> I still see the bug when I'm in X, even with an Emacs without X
>> support running in an xterm. It's the same on several GNU/Linux
>> systems, so I don't think I have misconfigured something.
>
> I don't see the bug when I'm in X, on my GNU/Linux laptop.  If you
> could post a detailed recipe, maybe that will help.

Thanks for taking the time to look at this. Unfortunately, I have no
idea what's going on here. I cannot describe many details regarding
the problem.

It seems to me that a process filter and/or process-send-string will
make this bug visible. The shell mode test was the easiest I could
think of, it uses a comint filter. If you can't reproduce the bug with
this, I don't know how to go with it.