Re: comint-interrupt-subjob also kills pending input

[Dan Jacobson]

Hmm, maybe make lines that didn't really get sent to the shell but got
interrupted still appear in the transcript (i.e. shell buffer record),
however with a # prepended.

Miles> Richard Stallman <rms@gnu.org> writes:
>> With your change it becomes much more difficult to do that.
>> 
>> It is trivial -- M-p brings it back.

Miles> Ah, I didn't realize that.  However, like the previous situation with
Miles> `C-y' yanking back the text, it seems likely that _most_ people won't
Miles> realize this.

Miles> It also results in a somewhat inconsistent situation that might confuse
Miles> users -- the `unsent' input is treated as if it had been sent to the
Miles> process in every way _except_ that wasn't sent (in particular, being put
Miles> into the `command ring', and being highlighted in bold like other 
`input').

Miles> Sometimes in fact it is very important to know what has been sent and
Miles> what hasn't, and this behavior confuses the issue (I guess you can
Miles> often [but not always] tell by looking for bold text followed by a
Miles> non-bold `C-c C-c', but again, this is `special knowledge' that a naive
Miles> user might not pick up on).

>> Instead of replacing `comint-kill-input' with `comint-skip-input', why
>> not just have nothing?
>> 
>> I don't like that.  C-c C-c in Emacs is supposed to be like C-c in
>> an ordinary terminal.  People could be painfully surprised if that
>> fails to discard the input.

Miles> I think rather they would be pleasantly surprised; this is something
Miles> that terminals can't do, but emacs can do easily and well.

Miles> I'm not sure why you think it would cause any pain, since it's
Miles> completely obvious what's going on (after all, the unsent input floats
Miles> ahead of any new input and is available for editing), and very easy to
Miles> delete the input using the normal editing procedures for command lines.
Miles> This is important, I think -- unlike every other behavior, it doesn't
Miles> require any special knowledge, you just edit like normal.

Miles> Personally, I find that it's _usually_ the case that when I hit C-c C-c
Miles> with unsent input, it's because I forgot to kill a program, and had
Miles> started to type the next command, and then suddenly realized what was
Miles> going on, and hit C-c C-c.  To me this seems like a common scenario,
Miles> and it's obviously one in which the assumption should be that the user
Miles> wants to keep the input.