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

[Nick Roberts]

 >    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