Re: Problems with debug-on-entry in the Lisp debugger.

[Lute Kamstra <Lute.Kamstra.lists@xs4all.nl>]

Stefan Monnier <monnier@iro.umontreal.ca> 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.