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

[Allen Li <darkfeline@felesatra.moe>]

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?