[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Lute Kamstra
Subject: Re: Problems with debug-on-entry in the Lisp debugger.
Date: Tue, 08 Mar 2005 19:57:26 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Stefan Monnier <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]