[PATCH] [RFC] Discard local stdin events while an attached inferior is running

[Patrick Palka]

On Tue, Jun 2, 2015 at 11:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Patrick Palka <patrick@parcs.ath.cx>
>> Cc: Patrick Palka <patrick@parcs.ath.cx>
>> Date: Tue,  2 Jun 2015 09:39:18 -0400
>>
>> This patch attempts to work around an annoying typo that I (and others,
>> I assume) commonly make while debugging an attached (not forked)
>> process.  That is, I sometimes type "continue\n\n" instead of
>> "continue\n" when I want to resume the inferior.  By doing so, the
>> inferior gets resumed and the extraneous "\n" gets buffered.  But once
>> GDB regains control, the extraneous "\n" gets read and so an empty
>> command line is submitted to readline.  This is shorthand for running
>> the previous command again.  So effectively typing "continue\n\n" will
>> run "continue" twice.  Running "continue" twice instead of once can have
>> irreversible consequences to the debugging session and thus is pretty
>> annoying to deal with.
>>
>> To work around this kind of typo, this patch installs a dummy event
>> handler that discards all local stdin events that occur when the
>> attached inferior is (synchronously) running.
>>
>> The obvious side-effect of this patch is that dexterous users can no
>> longer "queue" commands while an attached inferior is running, e.g.
>> type "continue\nprint foo" with the intention of "print foo" being run
>> as soon as GDB regains control.  I personally don't make use of this
>> ability very much.
>
> IMO, this incompatible change of behavior should at least have an
> option to get the old behavior back, and that option should possibly
> be off by default.
>
> In any case, there should be a NEWS entry and a patch for the manual
> which describe this unusual feature.

Will do, if there is enough support for this change to go forward.

>
>> Is this typo a common occurrence for anyone else?
>
> Not common, but sometimes.  However, I sometimes type ahead future
> commands without waiting for the prompt, for example, when I know I'll
> need a lot of CR presses.

Yeah, unfortunately it is impossible to determine whether a key press
was a typo or not :(

An alternative solution is to provide an option to disable the
repeat-command shorthand altogether.  It is slightly unintuitive,
typo-prone, and hardly an improvement over the well-known ^P<Enter>
key combination.