charles> I've noticed an odd behavior in edebug which I'm charles> attempting to fix. charles> I'm running XEmacs 21.1 (patch 14) with all lisp packages charles> up-to-date with the CVS repository (built locally). charles> If I bring up XEmacs, and in the *scratch* buffer, do charles> `M-x edebug-eval-top-level-form RET', I get the expected charles> message: charles> End of stream: #<buffer "*scratch*"> charles> After this I load a valid file of Elisp code and do `M-x charles> edebug-eval-top-level-form RET' again, I get charles> Symbol's value as variable is void: edebug-form-data charles> No subsequent attempts to use edebug meet with any charles> success. Hi Charles, I see the same problem in my native W2K (emacs-version) "XEmacs 21.5 (beta1) \"anise\" [Lucid] (i586-pc-win32) of Sat Jul 14 2001 on D5DC120J" I use M-x load-library RET edebug RET as a workaround. After that I can M-f11 (edebug-defun) successfully. Can't comment on the solution at this point. Best regards, Adrian charles> I noticed that in edebug.el, the variable charles> `edebug-form-data' is defconst'ed *before* it is set charles> buffer-local. charles> (make-variable-buffer-local 'edebug-form-data) charles> (defconst edebug-form-data nil) charles> Exchanging the order of these lines, so that it is charles> defconst'ed first and then set buffer-local, seems to fix charles> the problem. But I don't really understand why, and charles> before I submit a patch I'd like to understand what's charles> going on here. charles> Any clues? -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Kyle Jones <kyle_jones(a)wonderworks.com&gt; writes: I cannot help but wonder if it ever worked and how?