What the heck does this backtrace mean?

[Asfand Yar Qazi]

On 2/25/07, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Asfand Yar Qazi writes:
>  > Hi,
>  >
>  > 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
>  > /home/ayqazi/src/packages/xemacs/cvs/packages/xemacs-packages/ruby-modes/ruby-electric.el:
>  >   ** 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.
>
>

It was strange to me that I'd leave just a single new-line in the
file, and xemacs would bomb out when compiling it.

But I figured it out - I saw 'Raw:T' in the modeline for the file, and
after googling for it, realised that the file was NOT encoded in unix
end-of-line conventions or something.  I got it via a patch from
someone, so that must be why it ended up like that.  That's why xemacs
was bombing out.  Oh well, my xemacs experience grows daily... :-)