Stefan Monnier <[EMAIL PROTECTED]> writes: >> I can think of two points in a macro to set a break for the >> debugger: just before macro expansion and just after it, right >> before the evaluation of the resulting sexp. In both cases, >> hiding the debug-on-entry code from the user of the debugger >> seems not possible. > > To me "entry of a macro" is very clearly "just before expansion". > Especially if you think of macro-expansion occurring because of > explicit calls to macroexpand (e.g. in the byte-compiler) rather > than as a direct part of interpretation.
I see you implemented this. This makes debug-on-entry for macros a lot better, of course. Thanks. But the problem I mentioned remains: the debug-entry-code is visible. For example: (defmacro inc (var) (list 'setq var (list '1+ var))) (debug-on-entry 'inc) (progn (setq x 0) (inc x)) gives a backtrace like this: ------ Buffer: *Backtrace* ------ Debugger entered--entering a function: * (lambda (var) (if (or inhibit-debug-on-entry debugger-jumping-flag) nil (debug ...)) (list (quote setq) var (list ... var)))(x) (inc x) (progn (setq x 0) (inc x)) eval((progn (setq x 0) (inc x))) eval-last-sexp-1(nil) eval-last-sexp(nil) call-interactively(eval-last-sexp) ------ Buffer: *Backtrace* ------ >> Shall I go ahead and try to implement this, or do people think this >> is a bad idea? > > I think it's a bad idea. The interpreter is already way too slow, > I'd rather not make it worse. I think the effect on performance will be very minimal. Do you know of a good way to test the performance of the interpreter so that I can measure the impact of my proposed change? Can you indicate how much performance loss would be acceptable for you? Lute. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
