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

Previous Next

To reply to this bug, email your comments to 30059 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Allen Li <vianchielfaura <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.3; Wrong value for comint-process-echoes will cause
 comint-send-input to hang
Date: Tue, 9 Jan 2018 22:16:15 -0800

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'

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Allen Li <vianchielfaura <at> gmail.com>
Cc: 30059 <at> debbugs.gnu.org
Subject: Re: bug#30059: 25.3; Wrong value for comint-process-echoes will
 cause comint-send-input to hang
Date: Wed, 09 Dec 2020 19:36:36 +0100

Allen Li <vianchielfaura <at> 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

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

From: Allen Li <darkfeline <at> felesatra.moe>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 30059 <at> debbugs.gnu.org
Subject: Re: bug#30059: 25.3; Wrong value for comint-process-echoes will
 cause comint-send-input to hang
Date: Wed, 09 Dec 2020 19:36:06 -0800

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

> Allen Li <vianchielfaura <at> 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?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Allen Li <darkfeline <at> felesatra.moe>
Cc: 30059 <at> debbugs.gnu.org
Subject: Re: bug#30059: 25.3; Wrong value for comint-process-echoes will
 cause comint-send-input to hang
Date: Fri, 11 Dec 2020 15:42:14 +0100

Allen Li <darkfeline <at> 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

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

From: Richard Sharman <rsharman <at> pobox.com>
To: 30059 <at> debbugs.gnu.org
Subject: 25.3; Wrong value for comint-process-echoes will cause 
 comint-send-input to hang
Date: Sat, 6 Feb 2021 16:35:49 -0800

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

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

From: Richard Sharman <rsharman <at> pobox.com>
To: 30059 <at> debbugs.gnu.org
Subject: 25.3; Wrong value for comint-process-echoes will cause 
 comint-send-input to hang
Date: Sat, 6 Feb 2021 17:04:31 -0800

[Message part 1 (text/plain, inline)]

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].

[Patch-comint-send-input.txt (text/plain, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Richard Sharman <rsharman <at> pobox.com>
Cc: 30059 <at> debbugs.gnu.org
Subject: Re: bug#30059: 25.3; Wrong value for comint-process-echoes will
 cause comint-send-input to hang
Date: Fri, 13 Aug 2021 14:55:05 +0200

Richard Sharman <rsharman <at> 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

Previous Next

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