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

[Richard Stallman]

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

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

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

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

Please try these two replacement functions.


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

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

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

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> However, perhaps it would be better to treat that text as a previous
> input.  It has never been sent to the shell, and should not be, but it
> could be treated as if it had been.
> 
> Please try these two replacement functions.

I find that it's almost _always_ the case that when I interrupt a
process in shell-mode, and have pending input, that I want the input to
remain pending (so with the previous comint behavior, I'd almost always
immediately hit C-y).

With your change it becomes much more difficult to do that.

Instead of replacing `comint-kill-input' with `comint-skip-input', why
not just have nothing?  Then the input will remain pending; sometimes
people won't want that, but it's easy to remove with C-k or something
(and that would be a lot more obvious that the previous situation where
the input ended up in the kill-ring).

-Miles

-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: comint-interrupt-subjob also kills pending input

[Richard Stallman]

    I find that it's almost _always_ the case that when I interrupt a
    process in shell-mode, and have pending input, that I want the input to
    remain pending (so with the previous comint behavior, I'd almost always
    immediately hit C-y).

    With your change it becomes much more difficult to do that.

It is trivial -- M-p brings it back.

    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.

Re: comint-interrupt-subjob also kills pending input

[Stefan Monnier]

>     I find that it's almost _always_ the case that when I interrupt a
>     process in shell-mode, and have pending input, that I want the input to
>     remain pending (so with the previous comint behavior, I'd almost always
>     immediately hit C-y).
> 
>     With your change it becomes much more difficult to do that.
> 
> It is trivial -- M-p brings it back.
> 
>     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.

I for one would be happy to see Emacs keep the input, since I've
always been annoyed that shells don't keep it (especially since they
typically also fail to put the discarded input in the history so
M-p doesn't even work).


	Stefan

Re: comint-interrupt-subjob also kills pending input

[Miles Bader]

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.

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

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

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

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

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

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

-Miles
-- 
I'd rather be consing.

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.

Re: comint-interrupt-subjob also kills pending input

[Richard Stallman]

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

The C-c C-c at the end of the line should be a pretty clear indication
that it wasn't actually sent.  I don't see how people could fail to
grasp this.

    Personally, I find that it's _usually_ the case that when I hit C-c C-c
    with unsent input, it's because I forgot to kill a program, and had
    started to type the next command, and then suddenly realized what was
    going on, and hit C-c C-c.

Perhaps it should kill the input when the input follows a prompt
but not otherwise.  What do you think of that idea?

Re: comint-interrupt-subjob also kills pending input

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Personally, I find that it's _usually_ the case that when I hit C-c C-c
>     with unsent input, it's because I forgot to kill a program, and had
>     started to type the next command, and then suddenly realized what was
>     going on, and hit C-c C-c.
> 
> Perhaps it should kill the input when the input follows a prompt
> but not otherwise.  What do you think of that idea?

That would make sense, but I'm not sure how possible it is to do a good
job -- the code doesn't ever know when you're seeing a real prompt or
not, just that there's some non-newline-terminated output.  So if a
process displays something like `Pausing...' with no terminating
newline, comint's going to think it's a prompt until it sees more
output (in some sense, I suppose you could say that `Pausing...' _is_ a
prompt, inviting you to hit ^C!).

-MIles

-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: comint-interrupt-subjob also kills pending input

[Richard Stallman]

    > Perhaps it should kill the input when the input follows a prompt
    > but not otherwise.  What do you think of that idea?

    That would make sense, but I'm not sure how possible it is to do a good
    job -- the code doesn't ever know when you're seeing a real prompt or
    not, just that there's some non-newline-terminated output.

Comint has ways of recognizing prompts.  It has to have them.

Re: comint-interrupt-subjob also kills pending input

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     That would make sense, but I'm not sure how possible it is to do a good
>     job -- the code doesn't ever know when you're seeing a real prompt or
>     not, just that there's some non-newline-terminated output.
> 
> Comint has ways of recognizing prompts.  It has to have them.

The underlying process does not communicate which things are really
prompts, so it's impossible for comint to actually know for sure.
Comint currently has ways of _guessing_ which things are prompts, that
often do a `good enough job' for the tasks where they are used.

One way is the old `regexp' method, which is not used for most purposes
anymore.  It really sucks, because it guesses wrong insanely often; the
actual textual content of prompt is simply too varied and dynamic to
recognize this way.

Another way, used currently to highlight prompts, is to consider any
non-newline-terminated line at the end of the buffer a prompt, but to
update it dynamically so that any wrong guess (e.g. caused by partial
output) is quickly corrected.  Since one property of real prompts is
that the output pauses for input, this means that anything `noticeable'
as being highlighted as a prompt usually is one (when the user presses
RET, it `snapshots' the current prompt, guessing that the users' input
has validated that particular guess).

You can see that the latter will guess wrong in several situations,
(1) when output is split into several chunks, some of which don't end in
a newline, and (2) if the process outputs something that really doesn't
end in a newline, and then stops (but isn't actually waiting for input,
e.g. `Waiting for connection...' or something).

Case (1) is not a problem for prompt highlighting because it's fleeting
and not noticable.  Case (2) could be a considered ugly, but since it's
corrected as soon as the process finally outputs a newline, and while
waiting, the actual text of the output usually makes it clear whether
it's really a prompt or not, this isn't much of a problem in practice
(it's fairly rare for unix processes to do this sort of thing anyway).

So, for the `C-c C-c' case, the question is whether any of these wrong
guesses could cause problems.  I guess that in practice it would
normally not be a problem.

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

Re: comint-interrupt-subjob also kills pending input

[Richard Stallman]

    Another way, used currently to highlight prompts, is to consider any
    non-newline-terminated line at the end of the buffer a prompt, but to
    update it dynamically so that any wrong guess (e.g. caused by partial
    output) is quickly corrected.

Ok, I withdraw the suggestion to distinguish based on prompts.

Let's try making it an option whether to kill the input,
and then we can ask what users prefer.