Re: comint: 'C-c RET' changed unfavorabily

[Martin Maechler]

>>>>> "Nick" == Nick Roberts <address@hidden>
>>>>>     on Fri, 2 Sep 2005 08:42:16 +1200 writes:

    Nick> The two functions overlap (they both retrieve earlier
    Nick> input).  Can you give a simple example of how you use
    Nick> comint-copy-old-input in a way that doesn't work with
    Nick> comint-insert-input?
    >> 
    >> Sure; assuming M-x shell, i.e. buffer *shell*
    >> Use a few commands  ('ls', 'pwd', 'cd ..' etc)
    >> Now type C-c C-p at least once: This moves 'point' to one of the
    >> previous input lines;
    >> now  C-c RET  doesn't do anything in emacs 22, but it did what I
    >> have used it for, in Emacs <= 21.x ,
    >> namely 
    >> - copies the input line to the end of your *shell* buffer
    >> - moves 'point' (and scrolls if necessary) at the *end* of this line
    >> 
    >> such that another <return> simply would submit this line as a
    >> new line of input.  The practical use is that I often slightly
    >> change the line before resubmitting.
    >> 
    >> Is that sufficient?

    Nick> Emacs <= 21.x and Emacs 22 do the same thing for me.  Luc points out 
the
    Nick> C-c RET doesn't work when comint-use-prompt-regexp is non-nil.  What
    Nick> value do you have? (Its nil for me).

I see the bugous behavior in *shell* even when
comint-use-prompt-regexp is nil inside *shell*
but 't' inside *R* , an "inferior-ess" buffer:
That is needed by ESS (Emacs Speaks Statistics),
for good reasons I don't recall at the moment.


    Nick> Emacs 21 had two similar commands: comint-copy-old-input and
    Nick> comint-insert-clicked-input.  Having just one command 
(comint-insert-input)
    Nick> avoided unnnecessary duplication.  I think it is probably best to fix
    Nick> comint-insert-input to use comint-prompt-regexp when 
comint-use-prompt-regexp
    Nick> is non-nil rather than revert the change.

AFAI understand the issue, I agree...

    Nick> Nick

Martin