Re: DIagnostic messages... Where?

>>>>> "matthew" == matthew miner <[email protected]> writes:

    matthew> 1. What do these messages really mean (and I don't mean
    matthew> just the ones below, but all the messages that come up
    matthew> during compile).

I always found them self-explanatory.  Compilation is not that complex
a process in Emacs LISP, many transformations are practically
one-for-one from a special form or operator to a bytecode.  So the
byte compiler messages tend to be fairly straightforward comments on
syntax and program organization (unlike GCC's "pointer dereference at
XXXX in YYYY.c violates strict aliasing").

There is some explanation in the Lispref, node Byte Compilation,
especially the subnode Compilation Options.  Which sounds strange,
until you realize that the majority of compilation options are
actually pragmas to suppress warnings!

    matthew> 2. How to relate the messages to the corresponding lines?

That's a little annoying but not too hard, except in the case of
errors/warnings at top-level or very long functions.  Generally you
have to grep for the identifier being complained about.  You can also
use narrowing and `byte-compile-buffer' to do a binary search.

    matthew> I can't believe that anyone who put in the effort to make
    matthew> emacs so efficient to use would have left it so difficult
    matthew> to create new function.

Believe it.  GNU Emacs has no formal documentation on internals at
all, although the LISP manual is nearly complete and the User Manual
is good.  XEmacs is only a little better in that respect.

    matthew> Compiling file /home/jeaneid/.xemacs/comint.el at Thu Sep  1 09:01:46 2005

So we've got a file comint.el containing LISP code.

    matthew> While compiling comint-exec-1:

comint-exec-1 is a function or macro defined at top-level.  The syntax
being complained about is somewhere between the parentheses delimiting
the defun.

    matthew>   ** reference to free variable system-uses-terminfo

A reference is an attempt to use the value of a symbol.  So the
variable `system-uses-terminfo' occurs as an argument to a function or
special form that evaluates its arguments.

A free variable is one that is not bound in the current context, and
has not been declared via defvar.  This may be similar to GCC warning
about a variable that may be uninitialized.  Alternatively, it may
indicate a typo for a variable that was declared.

    matthew> While compiling comint-arguments:
    matthew>   ** variable value bound but not referenced

`value' occured in the bindings of a `let' or the like but was never
used.  Sometimes this is appropriate, but usually it's a symptom of
poorly maintained code.  This is inside the function `comint-arguments'.

    matthew> While compiling the end of the data:
    matthew>   ** The following functions are not known to be defined:
    matthew> read-event, posn-window, event-start,
    matthew> listify-key-sequence

This means that the file had balanced parentheses (otherwise you get
an "end of file encountered while compiling error"), and the symbols
were called somewhere in the file but the compiler doesn't know that
they are functions.  The compiler can be informed in one of three
ways: the function may have already been loaded into the LISP
environment (or an autoload cookie) before compilation started; the
function may be declared by requiring the file that contains it (this
doesn't change the LISP environment permanently); or the function may
be defined somewhere in the file being compiled (that's why it waits
until "end of data"---LISP doesn't need "forward declarations").

I'm not sure if this really helps, but AFAIK there is no
introductory-level glossary of byte-compiler errors.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.