[Bug: 21.4.19] C-c C-c in shell buffer broken with latest comint

[Jerry James]

Hi Mike,

Mike Kupfer <m.kupfer at acm.org> wrote:
> I fired up a shell, ran this command for a few iterations, moved point
> to the middle of the output, then entered C-c C-c to terminate the
> command.
>
>     $ while true; do date; sleep 2; done
>
> I expected to get a shell prompt, instead I got an XEmacs error in the
> minibuffer.  I could reproduce this with "xemacs -vanilla".  See below
> for a Lisp backtrace.  If I don't move point before entering C-c C-c, or
> if I do ESC > before entering C-c C-c, the command is terminated as
> expected.

When an extent is created with make-extent in comint.el:1842, it is
creating an extent such that extent-start-position, extent-end-position,
and extent-object all return nil.  I checked the numbers being given to
make-extent, and they are valid points in the buffer.  (In fact, they
have to be, since the first one is (point-at-bol) and the second one is
(point).)  I wondered if the extent object might be detached, given the
last sentence of the make-extent docstring:

  "The extent is initially detached if both FROM and TO are nil, and in
   this case BUFFER-OR-STRING defaults to nil, meaning the extent is in
   no buffer and no string."

but, no (extent-detached-p comint-last-prompt-extent) evaluates to nil.

Even weirder, I put a breakpoint on Fmake_extent and watched the extent
object get assembled with the correct buffer object and endpoints, and
then on continuing, watched Lisp trigger the same old error because the
extent object had neither buffer nor endpoints set.  So make-extent is
fine, but something is happening after it returns to nuke the contents
of the extent, or to change which extent comint-last-prompt-extent is
pointing to.

I'm out of time for now.  I'll carry on from there tomorrow.
-- 
Jerry James, Assistant Professor        james at xemacs.org
Computer Science Department             http://www.cs.usu.edu/~jerry/
Utah State University