From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lute Kamstra Newsgroups: gmane.emacs.devel Subject: Re: Problems with debug-on-entry in the Lisp debugger. Date: Tue, 08 Mar 2005 19:57:26 +0100 Message-ID: <87ll8yx8x5.fsf@xs4all.nl> References: <87sm37n2bv.fsf@xs4all.nl> <87hdjnegak.fsf-monnier+emacs@gnu.org> <876503wkh4.fsf@xs4all.nl> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1110309917 26849 80.91.229.2 (8 Mar 2005 19:25:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Mar 2005 19:25:17 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 08 20:25:17 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D8k8p-0004gx-5V for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2005 20:13:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D8kNL-0003oq-KN for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2005 14:28:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D8kFs-0002P0-Ds for emacs-devel@gnu.org; Tue, 08 Mar 2005 14:20:32 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D8kFd-0002J1-JL for emacs-devel@gnu.org; Tue, 08 Mar 2005 14:20:19 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D8kFd-0002GV-Dp for emacs-devel@gnu.org; Tue, 08 Mar 2005 14:20:17 -0500 Original-Received: from [194.109.24.23] (helo=smtp-vbr3.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D8jtY-0004fj-3L for emacs-devel@gnu.org; Tue, 08 Mar 2005 13:57:28 -0500 Original-Received: from pijl (a80-127-67-124.adsl.xs4all.nl [80.127.67.124]) by smtp-vbr3.xs4all.nl (8.12.11/8.12.11) with ESMTP id j28IvQ9t034770; Tue, 8 Mar 2005 19:57:27 +0100 (CET) (envelope-from Lute.Kamstra@xs4all.nl) Original-Received: from lute by pijl with local (Exim 3.36 #1 (Debian)) id 1D8jtX-0000Md-00; Tue, 08 Mar 2005 19:57:27 +0100 Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Mon, 07 Mar 2005 11:32:58 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Original-Lines: 45 X-Virus-Scanned: by XS4ALL Virus Scanner X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: news.gmane.org gmane.emacs.devel:34339 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34339 Stefan Monnier 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.