On Tue, 2002-11-26 at 23:18, Jerry James wrote:
In a vanilla XEmacs, cause semantic to be loaded (probably by
visiting a
Java file with JDE). Then visit any Lisp file, and use the menus to
choose Lisp -> Instrument This Defun for Debugging. The result is:
Signaling: (void-variable semantic-with-buffer-narrowed-to-command)
#<compiled-function nil "...(6)" [semantic-with-buffer-narrowed-to-command
def-edebug-spec def-body] 3>()
run-hooks(#<compiled-function nil "...(6)"
[semantic-with-buffer-narrowed-to-command def-edebug-spec def-body] 3>)
edebug-read-and-maybe-wrap-form()
edebug-read-top-level-form()
#<compiled-function nil "...(10)" [edebug-all-forms edebug-all-defs eval t
edebug-read-top-level-form] 3
("/tools/xemacs/xemacs-packages/lisp/edebug/edebug.elc" . 13815) nil>()
call-interactively(edebug-defun)
In semantic-ctxt.el, semantic-with-buffer-narrowed-to-command is defined
as a macro, and then used like this:
(add-hook 'edebug-setup-hook
(lambda ()
(def-edebug-spec semantic-with-buffer-narrowed-to-command
(def-body))))
But def-edebug-spec is also a macro, defined in edebug.el. A peek at
semantic-ctxt.elc seems to show that the macro was not expanded. Is
this another package dependency problem?
Certainly seems so to me. I dug somewhat into this, and began by adding
edebug to semantic's REQUIRES and make install'ing it.
The `semantic-with-buffer-narrowed-to-command' error went away, but I
got a very much similar error from `speedbar-with-writable' (using the
same recipe).
Ok, require edebug in speedbar, make install, try again: similar error,
this time from `defmethod'.
Proceed, require edebug in eieio, make install, try again, and no
errors!
So, looks like adding edebug to eieio's, semantic's and speedbar's
REQUIRES seems to (cure|work around) the problem. Could someone verify
the fix (better fixes welcome as well)?
--
\/ille Skyttä
scop at
xemacs.org