[twurgler@goodyear.com: Re: emacs 21.2 odd behavior in shell window]

[twurgler@goodyear.com: Re: emacs 21.2 odd behavior in shell window]

[Tom Wurgler]

Ok, I am back to the problem again.

HP-UX 11.0 compiled with cc.


Specifically,

I am in a shell window.  BTW, my default shell is csh, terminal type is "dumb".
I try to run a fortran program or a sh script, which prompt for a filename.
At the prompt for the filename, I decide that I want to kill it and do something
else.  So in all previous versions of emacs, I would hit ^C^C, which was bound
to comint-interupt-subjob and the program was aborted.

Now when I hit ^C^C in emacs 21.2, I get nothing.
I then hit ^H^C ^C^C and it says it is bound to comint-interupt-subjob.
I then type esc-: (comint-interupt-subjob) and the program is sucessfully
aborted. 



------- Start of forwarded message -------
Date: Thu, 28 Mar 2002 17:06:13 -0500 (EST)
From: Tom Wurgler <twurgler@goodyear.com>
To: rms@gnu.org
CC: twurgler@goodyear.com, bug-gnu-emacs@gnu.org
In-reply-to: <200203282048.g2SKmFn09727@aztec.santafe.edu> (message from
	Richard Stallman on Thu, 28 Mar 2002 13:48:15 -0700 (MST))
Subject: Re: emacs 21.2 odd behavior in shell window


Recently Richard Stallman <rms@gnu.org> wrote:

> Date: Thu, 28 Mar 2002 13:48:15 -0700 (MST)
> From: Richard Stallman <rms@gnu.org>
> CC: bug-gnu-emacs@gnu.org, t901353@rds294.goodyear.com
> Reply-to: rms@gnu.org
> 
>     Also in a shell, I used to be able to hit ^C^C to interrupt a subjob.
>     That no longer works.
> 
> What does it do?  What command does it actually run?
> What command is C-c C-c bound to in the shell buffer?
> 

I am unable to duplicate the problem (right now at least).  What I had (ever
since installing 21.2) was that if I started a program in a shell and it was
prompting for a filename or whatever, if I hit ^C^C it did *NOT* abort the
program.  But if I did esc-x comint-interupt-subjob, that *DID* abort it.  But
in checking the keystroke, it really was bound to `comint-interupt-subjob' as it
should have been.  I know it sounds dumb, but it did it repeatedly, hence my
note to the list.

The ^C^C did nothing at all.  No interupt, no beep, nada.

Not much help, I know.

I'll let you know if it re-occurs.

Thanks
tom
------- End of forwarded message -------

Re: [twurgler@goodyear.com: Re: emacs 21.2 odd behavior in shell window]

[Richard Stallman]

    Now when I hit ^C^C in emacs 21.2, I get nothing.
    I then hit ^H^C ^C^C and it says it is bound to comint-interupt-subjob.
    I then type esc-: (comint-interupt-subjob) and the program is sucessfully
    aborted. 

Please try redefining comint-interupt-subjob to run interpreted and
put (debug) into it at the beginning.  Then try stepping through it
and see what it does.

Re: [twurgler@goodyear.com: Re: emacs 21.2 odd behavior in shell window]

[Tom Wurgler]

Recently Richard Stallman <rms@gnu.org> wrote:

> Date: Mon, 1 Apr 2002 16:21:08 -0700 (MST)
> From: Richard Stallman <rms@gnu.org>
> CC: t901353@rds294.goodyear.com, bug-gnu-emacs@gnu.org
> Reply-to: rms@gnu.org
> 
>     Now when I hit ^C^C in emacs 21.2, I get nothing.
>     I then hit ^H^C ^C^C and it says it is bound to comint-interupt-subjob.
>     I then type esc-: (comint-interupt-subjob) and the program is sucessfully
>     aborted. 
> 
> Please try redefining comint-interupt-subjob to run interpreted and
> put (debug) into it at the beginning.  Then try stepping through it
> and see what it does.
> 
> 

Here is what I tried.  

I brought comint.el into a buffer, searched for "defun comint-interrupt-subjob"

Below the (interactive) I added a (debug) and set the region around the defun,
then did eval-region.

I then did ^C^C and stepped through no problem and eventually aborted the
program in the shell.  So I started the shell program again and did ^C^C.  When
the debug started I just hit C, it completed the abort just fine.

So I took out the debug line and eval'ed the defun again.  Now ^C^C aborted
the program just fine.

So I got out of emacs totally, restarted, tried the ^C^C again and it didn't
work.

So I brought comint.el into a buffer again, eval'ed just comint-interrupt-subjob
without adding or changing anything else.  Now ^C^C worked just fine.

Does any of this help?  (Is this what you meant to do when you said to run
"interpreted"?)

Thanks 
tom

Re: [twurgler@goodyear.com: Re: emacs 21.2 odd behavior in shell window]

[Richard Stallman]

    So I got out of emacs totally, restarted, tried the ^C^C again and it didn't
    work.

    So I brought comint.el into a buffer again, eval'ed just comint-interrupt-subjob
    without adding or changing anything else.  Now ^C^C worked just fine.

It sounds like the function works interpreted and fails compiled.
Can you verify that?

If so, the next step is to debug at C level.  Use GDB to put a
breakpoint at Finterrupt_process, and see if it gets called the same
way in both cases.  See what happens inside it in both cases.

Re: [twurgler@goodyear.com: Re: emacs 21.2 odd behavior in shell window]

[Tom Wurgler]

Recently Richard Stallman <rms@gnu.org> wrote:

> Date: Thu, 4 Apr 2002 23:02:45 -0700 (MST)
> From: Richard Stallman <rms@gnu.org>
> CC: twurgler@goodyear.com, bug-gnu-emacs@gnu.org
> Reply-to: rms@gnu.org
> 
> 
>     So I got out of emacs totally, restarted, tried the ^C^C again and it didn't
>     work.
> 
>     So I brought comint.el into a buffer again, eval'ed just comint-interrupt-subjob
>     without adding or changing anything else.  Now ^C^C worked just fine.
> 
> It sounds like the function works interpreted and fails compiled.
> Can you verify that?

I am not sure how to verify that.  

I renamed the comint.elc and then byte-compiled comint.el (I did this because
the .elc header said it was compiled with emacs-21.1).  This did not help.

If I eval the defun, ^C^C works.
If I run esc-: (comint-interrupt-subjob), the routine works.
Just not if I run it via ^C^C via the normal load etc.

If you can guide me a bit, I'll try to verify it...


> 
> If so, the next step is to debug at C level.  Use GDB to put a
> breakpoint at Finterrupt_process, and see if it gets called the same
> way in both cases.  See what happens inside it in both cases.
> 

Not good at this, but I'll give it a try...