From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: comint-insert-input on non-command lines: A trivial fix, a quibble, and a bug Date: Mon, 8 May 2006 12:31:16 +1200 Message-ID: <17502.37204.411491.461843@farnswood.snap.net.nz> References: <17501.373.791079.156322@rgrjr.dyndns.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1147048342 4704 80.91.229.2 (8 May 2006 00:32:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 8 May 2006 00:32:22 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 08 02:32:19 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Fctfa-0002G1-O2 for ged-emacs-devel@m.gmane.org; Mon, 08 May 2006 02:32:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FctfZ-0003iC-M1 for ged-emacs-devel@m.gmane.org; Sun, 07 May 2006 20:32:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FctfO-0003i6-8b for emacs-devel@gnu.org; Sun, 07 May 2006 20:32:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FctfM-0003gZ-C7 for emacs-devel@gnu.org; Sun, 07 May 2006 20:32:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FctfM-0003gJ-5K for emacs-devel@gnu.org; Sun, 07 May 2006 20:32:00 -0400 Original-Received: from [202.37.101.8] (helo=viper.snap.net.nz) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fctg4-0006uJ-9o for emacs-devel@gnu.org; Sun, 07 May 2006 20:32:44 -0400 Original-Received: from farnswood.snap.net.nz (p202-124-114-54.snap.net.nz [202.124.114.54]) by viper.snap.net.nz (Postfix) with ESMTP id DA5E275877D; Mon, 8 May 2006 12:31:56 +1200 (NZST) Original-Received: by farnswood.snap.net.nz (Postfix, from userid 500) id 500A9627ED; Mon, 8 May 2006 01:31:17 +0100 (BST) Original-To: Bob Rogers In-Reply-To: <17501.373.791079.156322@rgrjr.dyndns.org> X-Mailer: VM 7.19 under Emacs 22.0.50.47 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:54046 Archived-At: > First the fix (see the diff below): When you type "C-c RET" > (comint-insert-input) in shell mode (e.g.) with point on a line of > output, nothing happens, not even a ding. The name comint-insert-input suggests that it inserts (old) input so to do nothing when the point isn't over input seems appropriate to me. > This seems to be because > comint-insert-input is trying to invoke the "RET" binding, but doesn't > allow for the fact that this-command-keys returns a string. Its because comint-insert-input can also be invoked by mouse-2 which falls back to the global binding (generally mouse-yank-at-click). > The patch > makes it work for me, though only if you define "working" as "insert a > newline at point". A trivial fix is one thats simple to implement but this one doesn't seem to give the right result. > Hence the quibble: I would argue that these bindings are backwards. > There have been many times that I've typed "RET" (comint-send-input) in > a shell buffer and mistakenly expected newline insertion, instead of the > defined "reinvoke this command" behavior. Yes this behaviour can have unforeseen consequences and my preference would be to remove it. > In contrast, I never expect > insertion when I type "C-c RET"; besides which, the side-effects of an > accidental "C-c RET" are easier to undo. So if "safety" were the reason > ... It isn't the reason. We have tried to combine two commands with a similar functionality (comint-insert-clicked-input, comint-copy-old-input) > for changing comint-insert-input to work only on actual command input, > then it seems inconsistent not to do the same for comint-send-input as > well. Moreover, I would argue that comint-send-input should be the > picky one, and comint-insert-input should be more forgiving, so that you > could then get the current effect of "RET" on an arbitrary line by > typing "C-c RET RET", i.e. insert at the process mark and then submit > it. As it is, I see no way to get the former comint-copy-old-input > behavior, save by cut-and-paste. Or have I missed something? I see now that comint-copy-old-input did indeed copy the whole line but although the name would not suggest so. Presumably sometimes you need part of the line, in which case you would need to cut and paste anyway. > If not, that's the bug: I find it extremely useful to be able to > reinvoke lines of transcript output (e.g. commands echoed by "make") > after editing them, so it is frustrating that "C-c RET" no longer works > for that. Again the name comint-copy-old-input doesn't suggest this behaviour and my preference would be not to have it. > Even if the new behavior is deemed a feature (or gets > grandfathered due to release pressure), it amounts to an incompatible > change, but I can't find any mention of this in NEWS. (Except for the > command name, the description in misc.texi hasn't changed, though the > new behavior does match it better than the old behavior did.) That's right the behaviour you're describing wasn't documented. You're suggesting now that NEWS describe the removal of this undocumented behaviour. I think that might confuse people. > So the question is: Misfeature, or documentation oversight? Its Richard's call. If he wants comint-copy-old-input back I will reinstate it. -- Nick http://www.inet.net.nz/~nickrob