Path: utzoo!utgpu!watmath!uunet!cs.utexas.edu!usc!apple!bridge2!mdb From: mdb@bridge2.ESD.3Com.COM (Mark D. Baushke) Newsgroups: gnu.emacs.bug Subject: Re: FOLLOWUP TO Suspending Emacs in a shelltool Message-ID: Date: 6 Sep 89 03:17:12 GMT References: <8909040826.AA04025@purina> <1755@cbnewsl.ATT.COM> Sender: news@bridge2.ESD.3Com.COM Distribution: gnu Organization: 3Com Corp., Mountain View, CA. Lines: 37 In-reply-to: dog@cbnewsl.ATT.COM's message of 5 Sep 89 14:23:10 GMT In article <1755@cbnewsl.ATT.COM> dog@cbnewsl.ATT.COM (edward.n.schiebel) writes: ed> From article <8909040826.AA04025@purina>, by squash@BOSCO.BERKELEY.EDU: > ...stuff deleted... I typed a single C-g and the same symptoms that > C-z provoked occurred, namely, Emacs no longer saw my keyboard input (it > merely echoed in the Shelltool) ed> I have also seen this in emacstool (emacs 18.53, sun3, sunos 4.0.3) ed> but don't know how it happenes. It's in response to some mis-type ed> on my part. The only way to resume is kill the window entirely ed> and start over. ed> -Ed Schiebel You do not have to kill the window entirely and start over. Follow this procedure and you should be able to recover. do a ps command (from another window) to find the process number of the emacs process (NOT the emacstool process). issue the command 'kill -CONT emacs-process-number' to restart the suspended emacs (where emacs-process-number is the number from the ps command above) if it happened that your emacstool sent too many C-g interrupts in a burst, emacs will prompt you to 'autosave (y/n)' say 'y', it will ask if you want to dump core. say 'no' you will be able to continue where you left off. if it was not the 'too many interrupts' problem you will be back in emacs where you left off. Enjoy! -- Mark D. Baushke Internet: mdb@ESD.3Com.COM UUCP: {3comvax,auspex,sun}!bridge2!mdb