[Bug: 21.4.19] RET doesn't copy command line to current prompt

Mike Kupfer mike.kupfer at sun.com
Wed Jul 5 19:21:44 EDT 2006


>>>>> "Jerry" == Jerry James <james at xemacs.org> writes:

>> Here's the second of the two annoying behavior changes that I'm
>> seeing, going from xemacs-base 2.03 to xemacs-2.06.

Jerry> I must have missed the first one.  Can you point me to it?

Hmm, somehow the "to" address got munged in the original.  I've resent
it.

Jerry> If, in the body of find-field, we change the second let-form to
Jerry> this:

Jerry>       (let* ((ext (extent-at pos nil 'field))
Jerry>            (field (if ext (extent-property ext 'field))))

Jerry> that fixes the problem for me.  

Yup, works for me, too.  Thanks.

Jerry> they changed comint-send-input to take an optional argument,
Jerry> no-newline.  If no-newline is nil, then you get a newline
Jerry> inserted after the copy is made.  For shell mode, this means that
Jerry> C-m copies the old input and immediately sends it to the shell,
Jerry> without giving you a chance to edit it.  

Sigh, yeah, I can't say that change fills me with delight.

Jerry> Suggestions on how to fix this, and just how much Emacs
Jerry> compatibility we should strive for, are welcome.

Well, the docstring for comint-send-input implies that this is the
intended behavior.  It would be nice to have a way to override it, but
I'm not the person who would do future merges with the upstream
comint.el ;-).

I looked through the code a bit to understand what's going on.  It seems
odd to me that there is a global variable
comint-input-sender-no-newline, but comint-send-input always overrides
it with the value of no-newline.

Perhaps RET in shell mode could be bound to a wrapper function that does

    (comint-send-input comint-input-sender-no-newline)

?

cheers,
mike




More information about the XEmacs-Beta mailing list