RE: address@hidden: RE: weird defadvice bugwithbyte-compilation]

[Drew Adams]

    > It does, as far as I can tell. I don't understand all of it,
    > however, I admit. I still don't understand, for instance:
    >
    > 1. why byte-compiling the defadvice in bar.el would eval
    >    my-mode (my-mode does not even appear in bar.el)

    I think it doesn't eval it, it just sees that my-mode is not bound.
    The warning says "reference to free variable `my-mode'", see the
    backtrace.  This is a standard warning from the byte compiler, it is
    meant to help you detect typos in variable names.

OK. I was confused because it was the byte-compilation that led ultimately
to x-create-frame raising an unbound var error.

    > 2. why evaling the defadvice in foo.el would eval my-mode (the BODY of
    >    defadvice is not supposed to be quoted)

    Because defadvice byte-compiles the function it creates on the fly, I
    guess.

But it is only the defadvice in bar.el, not the defadvice in foo.el, that
has the keyword `compile'.

And even if it does byte-compile foo.el on the fly (for whatever reason),
why would it eval my-mode - the body of a defadvice is not supposed to need
to be quoted (it is not evaled by defadvice).

That is, I don't understand why a byte-compiler warning of a potentially
unbound variable would lead to a *Backtrace* being created - a warning is
not an error, and even byte-compiler errors (as opposed to warnings) do not
result in a *Backtrace*.

    > 5. why selecting (require 'foo) and doing eval-region does
    >    not manifest the bug, but putting the cursor after
    >   (require 'foo) and doing `C-x C-e' does manifest the bug.

    Because, by default, eval-expression-debug-on-error is t, and it
    affects C-x C-e.  If I set eval-expression-debug-on-error to nil,
    Emacs behaves with C-x C-e like it does with eval-region: it doesn't
    pop up the *Backtrace* buffer in a separate frame, and the bug doesn't
    happen.

Ah - thanks. That makes sense, given your explanation of the bug being
manifested in x-create-frame.

I don't understand, however, your statement that when the byte compiler
tries to display special-buffer *Compile Log* in a separate frame "it hits
the problem with the void variable again". What is the "problem with the
void variable"? For the byte-compiler it was only a question of displaying a
warning, there was no error to be raised. Why would display of *Compile Log*
in a separate frame raise an unbound-variable error?