Stefan Monnier <[EMAIL PROTECTED]> writes: >> 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. > [...] >> 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) > [...] > > Other than the aesthetic aspect (which we can fix by just removing the > offending line in an ad-hoc way),
Actually, I'd like to see the line, but not the "(if (or inhibit-debug-on-entry debugger-jumping-flag) nil (debug ...))". > does it have any real impact? It can be confusing for new users of the debugger: Hey, what's that doing in my function? Did I put that there? >> I think the effect on performance will be very minimal. > > But I see no compelling reason to pay this price. > > After all, we've live for many years with this elisp implementation > without nearly any complaint. That's not really a valid argument. The macro handling bug was in there for years without any complaint too. Yet you fixed it. ;-) > If the aesthetic aspect is just more serious now that we replace > (debug 'debug) with (if (or inhibit-debug-on-entry > debugger-jumping-flag) nil (debug 'debug)), we can define a function > named e.g. `debug-entering' that will do the checking of > inhibit-debug-on-entry and debugger-jumping-flag. That would be somewhat better. However, I still feel that moving debug-on-entry to the lisp interpreter is "the right thing". It makes the hole thing better a lot simpler. Lute. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
