comint-interrupt-subjob also kills pending input

comint-interrupt-subjob also kills pending input

[Dan Jacobson]

[Emacs 21.2]
C-c C-c runs the command comint-interrupt-subjob

Interrupt the current subjob.
This command __also kills the pending input__
between the process-mark and point.

Oh great.  A bonus service with no ifs ands or variables to control
it.

So I had typed

$ du /var/cache/wwwoffle/ftp/longandpainfulline C-c C-c
and I end up with
$
$

I'm just not used to things i typed disappearing.  No choice about it
mentioned. OK, never mind. I'll use undo.

why can't you leave the top line alone and put me at a fresh prompt?
it's not like i'm making a session log for submission to court and
there must not be some entry that was actually run.  At least there
should be a variable to control this behavior.  Yes, bash may also do
this too, but script(1) would still have the chars if one ran it.  And
the reason we use *shell* is sort of like why one would run script(1)...
-- 
http://jidanni.org/ Taiwan(04)25854780

Re: comint-interrupt-subjob also kills pending input

[Miles Bader]

jidanni@deadspam.com (Dan Jacobson) writes:
> Interrupt the current subjob.
> This command __also kills the pending input__
> between the process-mark and point.
>
> I'm just not used to things i typed disappearing.  No choice about it
> mentioned. OK, never mind. I'll use undo.

It also puts the killed text into the kill-ring, so you can just do C-y
at the new prompt.  I think that's easy enough...

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: comint-interrupt-subjob also kills pending input

[Dan Jacobson]

>>>>> "RMS" == Richard Stallman <rms@gnu.org> writes in the "devel"
>>>>> group:

RMS>     Interrupt the current subjob.
RMS>     This command __also kills the pending input__
RMS>     between the process-mark and point.

RMS> This is for compatibility with a shell running in an ordinary terminal.
RMS> Typing C-c there has the same effect.

True.  But maybe make a variable to avoid this if a user is picky.

RMS> In Emacs, you can yank it back with M-y.  You can't do that in an
RMS> ordinary terminal.

RMS> However, perhaps it would be better to treat that text as a previous
RMS> input.  It has never been sent to the shell, and should not be, but it
RMS> could be treated as if it had been.

RMS> Please try these two replacement functions.

I did, and: let: Wrong number of arguments: #[nil ......

RMS> (defun comint-interrupt-subjob ()
RMS>   "Interrupt the current subjob.
RMS> This command also kills the pending input
RMS> between the process-mark and point."
RMS>   (interactive)
RMS>   (comint-skip-input)
RMS>   (interrupt-process nil comint-ptyp))

RMS> (defun comint-skip-input ()
RMS>   "Skip all pending input, from last stuff output by interpreter to point.
RMS> This means mark it as if it had been sent as input, without sending it."
RMS>   (let ((comint-input-sender 'ignore)
RMS> 	(comint-input-filter-functions nil))
RMS>     (comint-send-input t))
RMS>   (end-of-line)
RMS>   (let ((pos (point))
RMS> 	(marker (process-mark (get-buffer-process (current-buffer)))))
RMS>     (insert "  " (key-description (this-command-keys)))
RMS>     (if (= marker pos)
RMS> 	(set-marker marker (point)))))
-- 
http://jidanni.org/ Taiwan(04)25854780

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.