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

[Nick Roberts <nickrob@snap.net.nz>]

 >    When comint-use-prompt-regexp is nil things should work as before.  When
 >    it is t, you should get the old behaviour i.e output lines are copied
 >    too.
 > 
 > Now C-c RET works indeed OK if comint-use-prompt-regexp is non-nil,
 > but now mouse-2 gives problems.  I do not believe that mouse-2 should
 > do anything but yank if comint-use-prompt-regexp is non-nil, since the
 > behavior is too confusing otherwise, without any help echo to warn or
 > anything.  Of course, the mouse-2 help-echo should also be made
 > conditional on comint-use-prompt-regexp being nil.

Luc, do you actually use comint?  You appear to know more about the variables
than me (perhaps from re-writing the manual) but I have been using mouse-2 to
insert input (in the GUD buffer) for a long time, and not found it confusing.

 > Also, people who find the old behavior useful will now have to set
 > comint-use-prompt-regexp non-nil for no other reason than to restore
 > that behavior.  To me, this seems weird. 

Fields provide the opportunity to distinguish between input and output:
I think we should use it.

 > You replaced comint-copy-old-input with comint-insert-input believing
 > that it was similar to comint-insert-clicked-input.  But it is not.
 > mouse-2 has an important global binding, yanking, and even overriding
 > that global binding for old input seems rather dubious, let alone
 > overriding it in the entire comint buffer, making yanking using
 > mouse-2 completely impossible.

What binding do you think comint-insert-clicked-input had?  It was mouse-2
and it overrode the global binding.  Perhaps you are also arguing against
that function which was introduced six years ago and in Emacs 21.

It doesn't make yanking impossible (try it), just yanking at previous input.

 > On the other hand, `C-c RET' has no important global binding, so there
 > is no reason not to use it on output.  The user gets the opportunity
 > to edit, so even _if_ he hit `C-c RET' by accident, which is very
 > unlikely, no major harm is done.  So providing the extra functionality
 > to people who find it useful does not impose any real hardship on
 > people who never use it.
 
Just like help-follow-mouse used to work on words which weren't
cross-references.

I think it lacks logic, adds complexity and just performs a task that can be
done with two mouse clicks anyway.

 > In certain derived Comint modes, like external Lisp mode, using `C-c RET'
 > on output seems even more often useful than in shell-mode, which,
 > if I understood correctly, is what Bob is concerned with.

If it is so useful, I wonder why it wasn't documented.  In fact the
documentation even suggests it wasn't intended to be used in this way.

 > I personally believe that restoring comint-copy-old-input would be a
 > good thing.  `comint-insert-input' has not been part of any release,
 > so if we ever plan to undo the change, now is the time to do it.

I think some of your assertions are wrong.

 > Regardless of whether comint-copy-old-input gets restored, I believe
 > that it would be good to make the mouse-2 binding and corresponding
 > help-echo conditional on comint-use-prompt-regexp being non-nil and
 > document that wherever the mouse-2 binding is mentioned.  I could do
 > that if there are no objections.

I don't even follow that, mouse-2 inserts input even when
comint-use-prompt-regexp being non-nil

-- 
Nick                                           http://www.inet.net.nz/~nickrob