comint-insert-input on non-command lines: A trivial fix, a quibble, and a bug

[Bob Rogers]

   From: Nick Roberts <address@hidden>
   Date: Tue, 9 May 2006 15:11:33 +1200

    > Perhaps, but that doesn't address the original issue, namely that in
    > comint-mode "C-c RET" is now less useful that it had been.

   You're quoting my reply to Luc.  My reply to you, which you appear to have
   ignored, did address the original issue.

At the time, it seemed more appropriate to reply indirectly; I now see
that that was a mistake.  My apologies.

    > But it doesn't address the original problem:  "C-c RET" still does
    > nothing when invoked on an output line.  Please find a solution below
    > that merges your changes with the guts of the comint-copy-old-input
    > definition from 21.3, restoring the original behavior.  If that is
    > satisfactory to everyone, then I will undertake to ensure that all of
    > the documentation is consistent.

   I've already said why I don't like it.  We haven't reached an agreement
   yet that this behaviour is desirable.

Yes, of course.  I only made an offer to follow up that was conditional
on acceptance.

   From: Nick Roberts <address@hidden>
   Date: Mon, 8 May 2006 12:31:16 +1200

    >    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.

The name comint-insert-input does suggest that it should be inserting
something, so I found "doing nothing" surprising.  At the very least, it
should explain why it is refusing do what I am obviously asking.

    >                                              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).

OK.  But why wouldn't this be a reasonable thing to do for keyboard
input as well?

    >                                            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)

So the loss of functionality was accidental, then?

    > 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.

Not necessarily.  It is often more convenient to copy the whole line,
then pare it down at the command prompt.

    >    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.

That depends on how narrowly you want to define "input."

   . . .

   From: Nick Roberts <address@hidden>
   Date: Tue, 9 May 2006 18:17:19 +1200

   Luc Teirlinck writes:
    > . . .
    > 
    > Was there any reason, other than merely a desire to combine two
    > somewhat similar commands, to get rid of comint-copy-old-input?
    > Was anything broken about it?

   I don't think so, but I made that change nearly two years ago.  Since then
   there hasn't exactly been a rush of bug reports, so I find it hard to
   believe that it's been that inconvenient.

Well, I found it within an hour of building emacs from CVS, having used
distro versions for many years now.  It's possible that I'm the only one
who ever uses C-c RET on output lines . . . but somehow I doubt that.

                                        -- Bob