bug#30059: 25.3; Wrong value for comint-process-echoes will cause comint-send-input to hang

bug#30059: 25.3; Wrong value for comint-process-echoes will cause comint-send-input to hang

[Allen Li]

If comint-process-echoes is set to t and the subprocess does not echo
input (e.g., Bash depending on configuration), comint-send-input (RET)
will hang on a long-running process that does not write output.

comint should remove the echoed input line asynchronously.

In GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2017-12-04 built on arojas
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

bug#30059: 25.3; Wrong value for comint-process-echoes will cause comint-send-input to hang

[Lars Ingebrigtsen]

Allen Li <vianchielfaura@gmail.com> writes:

> If comint-process-echoes is set to t and the subprocess does not echo
> input (e.g., Bash depending on configuration), comint-send-input (RET)
> will hang on a long-running process that does not write output.
>
> comint should remove the echoed input line asynchronously.

(This bug report unfortunately got no response at the time.)

This behaviour is still present in Emacs 28...  but is it a bug?  It's a
setting that's supposed to be used if the shell echoes the inputs, and
you're not supposed to use it if that's not the case.

Recipe to reproduce:

emacs -Q -f shell
M-: (setq comint-process-echoes t)
sleep 10

I'm leaning towards this working as intended.  Any opinions?

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

bug#30059: 25.3; Wrong value for comint-process-echoes will cause comint-send-input to hang

[Allen Li]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Allen Li <vianchielfaura@gmail.com> writes:
>
>> If comint-process-echoes is set to t and the subprocess does not echo
>> input (e.g., Bash depending on configuration), comint-send-input (RET)
>> will hang on a long-running process that does not write output.
>>
>> comint should remove the echoed input line asynchronously.
>
> (This bug report unfortunately got no response at the time.)
>
> This behaviour is still present in Emacs 28...  but is it a bug?  It's a
> setting that's supposed to be used if the shell echoes the inputs, and
> you're not supposed to use it if that's not the case.

Whether it's a bug is arguable, and I would argue that that is beside
the point.

Regardless of whether it is a bug, changing the behavior as I suggested
would improve the overall Emacs experience.  It should not be a
particularly difficult change IIRC from reading the code.  Of course, I
understand if making this change is not high priority.

Additional observation:

Setting comint-process-echoes "works" even if the process does not echo
(IIRC anyway); Emacs checks that the output doesn't match the input and
allows the output to pass unmodified.  It's only when the process
doesn't echo immediately that causes undesirable behavior.

Thus, this also affects the case where the process does echo, but only
after a delay.  Emacs will freeze while waiting for the echoed output,
which is undesirable.  Of course, this situation is likely to be rare as
a process that echoes generally echoes immediately.

>
> Recipe to reproduce:
>
> emacs -Q -f shell
> M-: (setq comint-process-echoes t)
> sleep 10
>
> I'm leaning towards this working as intended.  Any opinions?

bug#30059: 25.3; Wrong value for comint-process-echoes will cause comint-send-input to hang

[Lars Ingebrigtsen]

Allen Li <darkfeline@felesatra.moe> writes:

> Whether it's a bug is arguable, and I would argue that that is beside
> the point.
>
> Regardless of whether it is a bug, changing the behavior as I suggested
> would improve the overall Emacs experience.  It should not be a
> particularly difficult change IIRC from reading the code.  Of course, I
> understand if making this change is not high priority.

I'm not opposed to making comint be more asynchronous even if
comint-process-echoes is set.  Could you propose a patch for this,
perhaps?

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

bug#30059: 25.3; Wrong value for comint-process-echoes will cause comint-send-input to hang

[Richard Sharman]

I’ve been hit by this a few times and it’s quite annoying.  Starting from emacs -Q evaluate the following 2 lines

(setq comint-process-echoes t)
(shell)

then at the shell command enter “cat -n” .  This completely locks up emacs (at least under macos 10.13);  control-G and control-C have no effect; the emacs process has to be killed.



In GNU Emacs 27.1 (build 2, x86_64-apple-darwin17.7.0, NS appkit-1561.61 Version 10.13.6 (Build 17G14033))
 of 2020-12-13 built on henry.local
Windowing system distributor 'Apple', version 10.3.1561
System Description:  Mac OS X 10.13.6

bug#30059: 25.3; Wrong value for comint-process-echoes will cause comint-send-input to hang

[Richard Sharman]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

A simple fix is to add a timeout value to the call to accept-process-output.  For example, adding a 1 second timeout not only allows it to recover but also allows Control-g to be honoured.  Because control-g now is not ignored, the value could be increased substantially, say to 10 [seconds].


[-- Attachment #2: Patch-comint-send-input.txt --]
[-- Type: text/plain, Size: 530 bytes --]

--- comint.el.orig	2021-02-06 16:55:28.000000000 -0800
+++ comint.el	2021-02-06 16:57:24.000000000 -0800
@@ -1922,7 +1922,7 @@
             ;; Wait for all input to be echoed:
             (while (and (> (+ comint-last-input-end echo-len)
                            (point-max))
-                        (accept-process-output proc)
+                        (accept-process-output proc 1)
                         (zerop
                          (compare-buffer-substrings
                           nil comint-last-input-start

bug#30059: 25.3; Wrong value for comint-process-echoes will cause comint-send-input to hang

[Lars Ingebrigtsen]

Richard Sharman <rsharman@pobox.com> writes:

> I’ve been hit by this a few times and it’s quite annoying.  Starting
> from emacs -Q evaluate the following 2 lines
>
> (setq comint-process-echoes t)
> (shell)
>
> then at the shell command enter “cat -n” .  This completely locks up
> emacs (at least under macos 10.13); control-G and control-C have no
> effect; the emacs process has to be killed.

I can reproduce this in Emacs 27.1, but `C-g' works fine in Emacs 28 (at
least in Debian).

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