damerell@NSFNET-RELAY.AC.UK (Dr R M Damerell, RHBNC) (08/02/89)
I am trying to write a program in Emacs Lisp for indenting Pascal, etc, and
would much appreciate advice on some difficulties:
1. When I try to load-file and the file has syntax errors, I cannot see any
indication of where the error was detected. Is there any way to get this? (I do
appreciate that the real error may be a long way away from the detected error,
but some errors such as "invalid read syntax" are usually detected at the right
place; and at worst, you would know you need not search the file after the place
where the error was found).
2. The byte compiler is better in this respect because it seems to display the
names of successful defvars and defuns . Unfortunately they appear in the
minibuffer too fast for me to read them. Please is there any way to recover
error messages from the minibuffer?
3. Trying to debug a byte-compiled program, I get byte codes that fall off the
right hand margin of the backtrace buffer's window. Is there a way to tell
debug to wrap them onto the next line?
4. What is the intended effect of end-of-defun when one defun is nested in
another? The following code is accepted by load-file and the functions do
what I expect. If you point at BB and type C-M-e you move to DD instead
of CC . C-U -1 C-M-e also does peculiar things.
(defun a()
(setq z 1)
;;; AA
(defun b ( y)
(setq w (+ y z) ))
;;; BB
(b 3)
w)
;;; CC
(defun c ()
17)
;;; DD
5. Regular expressions. The Emacs Manual (sec 13.5) gives an example and I think
it does not explain it properly. Please could the following text be added at
the end of the section:
Note that this is how the regexp must be spelt when you are entering it to an
Emacs Lisp program. To enter the same regexp to an interactive command such as
@code{re-search-forward} you must spell it differently:
@example
[.?!][]"')]*\($\|^Q^I\| \)[ ^Q^I^Q^J]*
@end example
R.M.Damerellrbj@DSYS.NCSL.NIST.GOV (Root Boy Jim) (08/18/89)
? From: Dr R M Damerell (RHBNC) <damerell@nsfnet-relay.ac.uk> ? 1. When I try to load-file and the file has syntax errors, I cannot ? see any indication of where the error was detected. Is there any way ? to get this? (I do appreciate that the real error may be a long way ? away from the detected error, but some errors such as "invalid read ? syntax" are usually detected at the right place; and at worst, you ? would know you need not search the file after the place where the ? error was found). Perhaps a combination of eval-defun and forward-sexp in the buffer to be loaded will work. I don't know whether debug-on-error works when loading or not. ? 2. The byte compiler is better in this respect because it seems to ? display the names of successful defvars and defuns . Unfortunately ? they appear in the minibuffer too fast for me to read them. Please ? is there any way to recover error messages from the minibuffer? Someone posted some code once to save the messages in a ring buffer. ? 3. Trying to debug a byte-compiled program, I get byte codes that ? fall off the right hand margin of the backtrace buffer's window. Is ? there a way to tell debug to wrap them onto the next line? Well, you can use scroll-left, but who wants to look at byte-code? ? 4. What is the intended effect of end-of-defun when one defun is nested in ? another? The following code is accepted by load-file and the functions do ? what I expect. If you point at BB and type C-M-e you move to DD instead ? of CC . C-U -1 C-M-e also does peculiar things. ? (defun a() ? (setq z 1) ? ;;; AA ? (defun b ( y) ? (setq w (+ y z) )) ? ;;; BB ? (b 3) ? w) ? ;;; CC ? (defun c () ? 17) ? ;;; DD Dunno. I try to avoid this. ? R.M.Damerell Root Boy Jim Have GNU, Will Travel.
arc1@ukc.ac.uk (A.R.Curtis) (08/18/89)
In article <8908172214.AA15126@dsys.ncsl.nist.gov> rbj@DSYS.NCSL.NIST.GOV (Root Boy Jim) writes: > >? 2. The byte compiler is better in this respect because it seems to >? display the names of successful defvars and defuns . Unfortunately >? they appear in the minibuffer too fast for me to read them. Please >? is there any way to recover error messages from the minibuffer? > >Someone posted some code once to save the messages in a ring buffer. > You can always use batch mode to byte-compile within a shell. E.g. emacs -batch -f batch-byte-compile elispfile.el and then it's much easier to follow what is going on. Tony Curtis
jr@bbn.com (John Robinson) (08/31/89)
In article <8908172214.AA15126@dsys.ncsl.nist.gov>, rbj@DSYS (Root Boy Jim) writes: >? From: Dr R M Damerell (RHBNC) <damerell@nsfnet-relay.ac.uk> > >? 1. When I try to load-file and the file has syntax errors, I cannot >? see any indication of where the error was detected. Is there any way >? to get this? > >Perhaps a combination of eval-defun and forward-sexp in the buffer to >be loaded will work. I don't know whether debug-on-error works when >loading or not. Use eval-region and binary-search the buffer. Also, debug-on-error ought to help some I think. To check for paren balancing, go to the end of the file and insert a ) . Emacs ought to complain if parens are unbalanced. Then delete that ) and the one before it. Emacs ought to show you a matching paren (check that it's the right one). This assume you are in some form of lisp mode. >? 3. Trying to debug a byte-compiled program, I get byte codes that >? fall off the right hand margin of the backtrace buffer's window. Is >? there a way to tell debug to wrap them onto the next line? > >Well, you can use scroll-left, but who wants to look at byte-code? Find the defun for the function and eval-defun or eval-last-sexp on it. Now it won't be in byte-code any longer. This is also one way to undo a debug-on-entry. Once the code is fixed and re-byte-compiled, load the compiled file to speed it up again. >? R.M.Damerell > > Root Boy Jim > Have GNU, Will Travel. -- /jr, nee John Robinson Life did not take over the globe by combat, jr@bbn.com or bbn!jr but by networking -- Lynn Margulis
liberte@m.cs.uiuc.edu (09/05/89)
> /* Written 9:28 am Aug 31, 1989 by jr@bbn.com in m.cs.uiuc.edu:gnu.emacs */ > To check for paren balancing, go to the end of the file and insert a > ) . Emacs ought to complain if parens are unbalanced. Then delete > that ) and the one before it. Emacs ought to show you a matching > paren (check that it's the right one). This assume you are in some > form of lisp mode. > /* End of text from m.cs.uiuc.edu:gnu.emacs */ Emacs doesnt always look far enough for a matching paren to bounce to. Instead of relying on that, I use forward and backward sexp motion; that also moves me closer to where the error is. So if you get end of file during parsing, you are missing one or more right parens. Go to the end of file and insert a right paren, and then move back one sexp to find the start of the sexp in error. If instead, you have "extra" right parens, go to the beginning of file and insert a left paren, back up to before that paren and move forward one sexp to find the first extra right paren. These tricks will catch most paren errors. However, other kinds of errors may exist in top-level forms (e.g. bad char, or error during eval). One way to catch many of these errors is to turn on debug-on-error. Then during an eval-current-buffer, the debug window will pop up and the point for the buffer you just evaluated will be at the error. Dan LaLiberte uiucdcs!liberte liberte@cs.uiuc.edu liberte%a.cs.uiuc.edu@uiucvmd.bitnet