Asfand Yar Qazi writes:
I'm the emacs-lisp n00b who's audaciously decided to take over
maintenance of ruby-modes.
I'm having a great deal of difficulty figuring out what the dickens
the backtrace means. I can't even see where it's telling me the line
number or method name it failed on.
It doesn't tell you that. Lisp is s-expression-oriented, ie all it
really knows about are balanced parentheses. Because of the pervasive
use of macros (many standard control structures are implemented as
macros), it is very difficult to keep track of the position in the
original file. The Lisp byte-compiler doesn't even try.
While compiling ruby-electric-mode in file
** reference to free variable ruby-electric-mode-hook
** reference to free variable ruby-electric-mode-on-hook
** reference to free variable ruby-electric-mode-off-hook
While compiling toplevel forms:
!! End of file or stream ((#<buffer " *Compiler Input*">))
This means that the compiler expected more input. This almost always
means unbalanced parentheses, more rarely a typo of the wrong kind of
parenthesis. Finding the error generally requires the programmer to
look at the code. Consider
(when (emacs-version >= 21 5)
(setq debug-on-error t)
(defun newfunction () (message "that's not my job mon!"))
Is the defun subject to the when, or not? How is the poor compiler
supposed to guess?
To diagnose, go to the beginning of the file, and type
M-: (while t (set-mark) (forward-sexp 1)) RET
When the error occurs you can then use C-x C-x to find the beginning
of the unterminated sexp. At that point, enter that sexp, and you can
start stepping forward with C-M-f (forward-sexp), and when you go
farther than you expect, that's the sexp with a problem. Recurse
until the problem is obvious. ;-)
Another technique is to step through a function typing TAB. When a
line unexpectedly reindents, you've found a place where the programmer
and Emacs disagree about sexp structure.
XEmacs-Beta mailing list