pdg@chinet.chi.il.us (Paul Guthrie) (05/15/89)
In article <822@pcsbst.UUCP> jkh@pcsbst.UUCP (jkh) writes: >Question: Is there some way to get more information than "Error in init file" >when emacs doesn't like your .emacs file? This is what I use: (setq debug-on-error t) ; Rest of .emacs goes here (setq debug-on error nil) -- Paul Guthrie chinet!nsacray!paul
conway@hpdtl.HP.COM (Daniel F. Conway) (05/17/89)
pdg@chinet.chi.il.us (Paul Guthrie) writes: > In article <822@pcsbst.UUCP> jkh@pcsbst.UUCP (jkh) writes: > >Question: Is there some way to get more information than "Error in init file" > >when emacs doesn't like your .emacs file? > > This is what I use: > > (setq debug-on-error t) > > ; Rest of .emacs goes here > > (setq debug-on error nil) That was one of the first things that I tried when I got the message 'error in init file'. Unfortunately, setting debug on like this does not seem to take effect until after the init file is read, at least not under version 18.52, so I still get the bogus error message if my init file is bad. I have found that when this occurs, I can do a load-file in the scratch buffer with the init file and find where the error is. I'd still rather be able to get a meaningful error message while the init file is being read instead of having to do manual pushups to find the problem. Dan Conway dan_conway@hplabs.hp.com
jr@bbn.com (John Robinson) (05/19/89)
In article <6930010@hpdtl.HP.COM>, conway@hpdtl (Daniel F. Conway) writes: > Unfortunately, setting debug on like this does not seem to take >effect until after the init file is read, at least not under version 18.52, so >I still get the bogus error message if my init file is bad. I have found that >when this occurs, I can do a load-file in the scratch buffer with the init >file and find where the error is. I'd still rather be able to get a >meaningful error message while the init file is being read instead of having >to do manual pushups to find the problem. How about leaving the (setq debug-on-error t) in your .emacs, and starting emacs this way when you have problems: emacs -q -l ~/.emacs If emacs had the right function, you could leave the debug-on-error out of .emacs and issue: emacs -q -f set-debug-on-error -l ~/.emacs or maybe there should be a run-time switch to have this effect. /jr /jr, nee John Robinson What a waste it is to lose one's mind--or not jr@bbn.com or bbn!jr to have a mind. How true that is. -Dan Quayle
Ram-Ashwin@cs.yale.edu (Ashwin Ram) (05/20/89)
In article <40186@bbn.COM>, jr@bbn.com (John Robinson) writes: > In article <6930010@hpdtl.HP.COM>, conway@hpdtl (Daniel F. Conway) writes: > > Unfortunately, setting debug on like this does not seem to take > >effect until after the init file is read, at least not under version 18.52, so > >I still get the bogus error message if my init file is bad. I have found that > >when this occurs, I can do a load-file in the scratch buffer with the init > >file and find where the error is. > > If emacs had the right function, you could leave the debug-on-error > out of .emacs and issue: > > emacs -q -f set-debug-on-error -l ~/.emacs > > or maybe there should be a run-time switch to have this effect. It would be nice if you could always ask for a backtrace after an error occurred. The purpose of "debug-on-error" would then be to have this happen automatically if desired. Most Lisp systems (and even some shells) provide a "backtrace" command that can be invoked after an error has occurred, without having to "anticipate" the error (i.e., without having to turn on any flags in advance). This would take care of Daniel's problem, and would be very useful in other situations too. -- Ashwin.
jcgs@wundt.harlqn.uucp (John Sturdy) (05/23/89)
Ashwin writes: >> It would be nice if you could always ask for a backtrace after an error >> occurred. The purpose of "debug-on-error" would then be to have this happen >> automatically if desired. Try (setq stack-trace-on-error t) -- but, like debug-on-entry, it does not work while doing your .emacs! __John (jcgs@uk.co.harlqn)
Ram-Ashwin@cs.yale.edu (Ashwin Ram) (05/25/89)
In article <JCGS.89May23103137@wundt.harlqn.uucp>, jcgs@wundt.harlqn.uucp (John Sturdy) writes: > Ashwin writes: > >> It would be nice if you could always ask for a backtrace after an error > >> occurred. The purpose of "debug-on-error" would then be to have this happen > >> automatically if desired. > Try (setq stack-trace-on-error t) -- but, like debug-on-entry, it does > not work while doing your .emacs! stack-trace-on-error is like debug-on-error in that it automatically gives you a backtrace whenever there is an error, if you've setq'd it to t beforehand. But this (a) can get annoying and (b) does not allow you to debug unanticipated errors. What you want is a way to ask for a backtrace AFTER an error has occurred so that you can choose which errors you want to debug (rather than have every error put you into the debugger), and so that you can debug errors even if you didn't turn on debug-on-error or stack-trace-on-error earlier. -- Ashwin.
jcgs@wundt.harlqn.uucp (John Sturdy) (05/26/89)
In <61618@yale-celray.yale.UUCP>, Ashwin writes: >> What you want is a way to ask for a backtrace AFTER an error has >> occurred so that you can choose which errors you want to debug >> (rather than have every error put you into the debugger), and so >> that you can debug errors even if you didn't turn on debug-on-error >> or stack-trace-on-error earlier. I agree. How about a flag to control whether the *Backtrace* buffer is popped up on screen? Then you could look at the backtrace if you wanted to, but it wouldn't pester you if you didn't. A combination of that, and of making \C-G not produce a backtrace, would suit me fine. __John (jcgs@uk.co.harlqn) -- __John The Lord bless you and watch over you, The Lord make his face shine upon you and be gracious to you, The Lord look kindly on you and give you peace; My brothers, my sisters, God bless you. Amen. (St. Francis)