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

[Nick Roberts]

Luc Teirlinck writes:
 > Nick Roberts wrote:
 > 
 >    Since Miles has provided a patch that fixes the bug you pointed out, there
 >    is no longer an immediate need to purge comint-prompt-regexp in any case
 > 
 > I do not have the impression that Miles' patch fixes the bug with
 > comint-use-prompt-regexp that I pointed out.  Such a fix would require
 > using the variable comint-get-old-input again.

Well it fixes:

  Yes, but if comint-use-prompt-regexp is t, then comint-insert-input
  does nothing even if point _is_ over input.

I can't see that you pointed anything else out.

 > Note that `comint-insert-input' takes away the possibility that
 > derived modes had to adapt the behavior of `comint-copy-old-input' to
 > the peculiarities of the particular derived mode through the variable
 > comint-get-old-input, a possibility actually used in ielm buffers,
 > external Lisp buffers and Scheme buffers (and maybe by some external
 > packages).  

Why would they want to `adapt' comint-copy-old-input?  They seem to use
comint-get-old-input which *is* stll present in comint.el.

 >                This also breaks the similarity between RET
 > (comint-send-input) and C-RET, because RET still uses the variable
 > comint-get-old-input and thereby still respects mode-specific
 > implementations.

Yes, and I suggested making RET more like C-c RET since inadvertantly sending
output lines as input is inherently dangerous.

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


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