[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: new fboundp behavior weird
From: |
Drew Adams |
Subject: |
RE: new fboundp behavior weird |
Date: |
Sat, 29 Dec 2012 12:56:42 -0800 |
> debug-on-entry is using `fboundp'.
I don't think the call to fboundp in debug-on-entry is a problem - it is only in
the `interactive' spec. And (fboundp 'foo) correctly returns t.
The problem is perhaps due to Emacs 24's removal of this part of debug-on-entry
(from Emacs 23), which handles aliased functions:
;; The function is built-in or aliased to another function.
;; Create a wrapper in which we can add the debug call.
(fset function `(lambda (&rest debug-on-entry-args)
,(interactive-form (symbol-function function))
(apply ',(symbol-function function)
debug-on-entry-args)))
Dunno. Whatever the cause, the debugger does not show a frame for bar - it
seems to treat foo as if it were bar.
> (defalias 'foo 'bar)
> (setq debug-on-error t)
> M-x debug-on-entry RET foo TAB
> And then you get the error.
Yes, evalling (foo) using C-x C-e raises the error, in both 24.2 and trunk:
Debugger entered--Lisp error: (void-function foo)
(foo)
eval((foo) nil)
eval-last-sexp-1(nil)
eval-last-sexp(nil)
call-interactively(eval-last-sexp nil nil)
But in Emacs 23 (and prior) that does not happen. Instead, this:
Debugger entered--Lisp error: (void-function bar)
* bar()
* apply(bar nil)
* foo()
eval((foo))
eval-last-sexp-1(nil)
eval-last-sexp(nil)
call-interactively(eval-last-sexp nil nil)
I agree that there is a bug, presumably in the debugger. I don't think there is
a problem with fboundp, however. (fboundp 'foo) correctly returns t.
Re: new fboundp behavior weird, Andreas Schwab, 2012/12/29
Re: new fboundp behavior weird, Stefan Monnier, 2012/12/30