* Re: comint-interrupt-subjob also kills pending input [not found] <m2sn3qnaa2.fsf@jidanni.org> @ 2002-06-14 15:47 ` Richard Stallman 2002-06-17 2:21 ` Miles Bader 0 siblings, 1 reply; 10+ messages in thread From: Richard Stallman @ 2002-06-14 15:47 UTC (permalink / raw) Cc: emacs-devel 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))))) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: comint-interrupt-subjob also kills pending input 2002-06-14 15:47 ` comint-interrupt-subjob also kills pending input Richard Stallman @ 2002-06-17 2:21 ` Miles Bader 2002-06-18 8:10 ` Richard Stallman 0 siblings, 1 reply; 10+ messages in thread From: Miles Bader @ 2002-06-17 2:21 UTC (permalink / raw) Cc: jidanni, emacs-devel 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_) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: comint-interrupt-subjob also kills pending input 2002-06-17 2:21 ` Miles Bader @ 2002-06-18 8:10 ` Richard Stallman 2002-06-18 14:55 ` Stefan Monnier 2002-06-19 1:32 ` Miles Bader 0 siblings, 2 replies; 10+ messages in thread From: Richard Stallman @ 2002-06-18 8:10 UTC (permalink / raw) Cc: jidanni, emacs-devel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: comint-interrupt-subjob also kills pending input 2002-06-18 8:10 ` Richard Stallman @ 2002-06-18 14:55 ` Stefan Monnier 2002-06-19 1:32 ` Miles Bader 1 sibling, 0 replies; 10+ messages in thread From: Stefan Monnier @ 2002-06-18 14:55 UTC (permalink / raw) Cc: miles, jidanni, emacs-devel > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: comint-interrupt-subjob also kills pending input 2002-06-18 8:10 ` Richard Stallman 2002-06-18 14:55 ` Stefan Monnier @ 2002-06-19 1:32 ` Miles Bader 2002-06-20 14:34 ` Richard Stallman 1 sibling, 1 reply; 10+ messages in thread From: Miles Bader @ 2002-06-19 1:32 UTC (permalink / raw) Cc: jidanni, emacs-devel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: comint-interrupt-subjob also kills pending input 2002-06-19 1:32 ` Miles Bader @ 2002-06-20 14:34 ` Richard Stallman 2002-06-20 20:02 ` Miles Bader 0 siblings, 1 reply; 10+ messages in thread From: Richard Stallman @ 2002-06-20 14:34 UTC (permalink / raw) Cc: jidanni, emacs-devel 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? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: comint-interrupt-subjob also kills pending input 2002-06-20 14:34 ` Richard Stallman @ 2002-06-20 20:02 ` Miles Bader 2002-06-22 22:52 ` Richard Stallman 0 siblings, 1 reply; 10+ messages in thread From: Miles Bader @ 2002-06-20 20:02 UTC (permalink / raw) Cc: jidanni, emacs-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: comint-interrupt-subjob also kills pending input 2002-06-20 20:02 ` Miles Bader @ 2002-06-22 22:52 ` Richard Stallman 2002-06-23 0:12 ` Miles Bader 0 siblings, 1 reply; 10+ messages in thread From: Richard Stallman @ 2002-06-22 22:52 UTC (permalink / raw) Cc: jidanni, emacs-devel > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: comint-interrupt-subjob also kills pending input 2002-06-22 22:52 ` Richard Stallman @ 2002-06-23 0:12 ` Miles Bader 2002-06-24 9:33 ` Richard Stallman 0 siblings, 1 reply; 10+ messages in thread From: Miles Bader @ 2002-06-23 0:12 UTC (permalink / raw) Cc: jidanni, emacs-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: comint-interrupt-subjob also kills pending input 2002-06-23 0:12 ` Miles Bader @ 2002-06-24 9:33 ` Richard Stallman 0 siblings, 0 replies; 10+ messages in thread From: Richard Stallman @ 2002-06-24 9:33 UTC (permalink / raw) Cc: jidanni, emacs-devel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2002-06-24 9:33 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <m2sn3qnaa2.fsf@jidanni.org> 2002-06-14 15:47 ` comint-interrupt-subjob also kills pending input Richard Stallman 2002-06-17 2:21 ` Miles Bader 2002-06-18 8:10 ` Richard Stallman 2002-06-18 14:55 ` Stefan Monnier 2002-06-19 1:32 ` Miles Bader 2002-06-20 14:34 ` Richard Stallman 2002-06-20 20:02 ` Miles Bader 2002-06-22 22:52 ` Richard Stallman 2002-06-23 0:12 ` Miles Bader 2002-06-24 9:33 ` Richard Stallman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).