From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.bugs Subject: bug#33201: 26.1; Edebug doesn't work on closures with edebug-unwrap-results Date: Thu, 01 Nov 2018 16:06:12 -0700 Message-ID: <871s84jt3v.fsf@runbox.com> References: <20181031150627.67149.qmail@mail.muc.de> <20181101100056.GA4504@ACM> <83sh0khdf6.fsf@gnu.org> <20181101195918.GD4504@ACM> <83bm78h7q7.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1541113572 20630 195.159.176.226 (1 Nov 2018 23:06:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Nov 2018 23:06:12 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) Cc: Alan Mackenzie , 33201@debbugs.gnu.org, darkfeline@felesatra.moe To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 02 00:06:07 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gIM2N-0005DI-U6 for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Nov 2018 00:06:04 +0100 Original-Received: from localhost ([::1]:47048 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIM4U-0002FU-8M for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Nov 2018 19:08:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIM4N-00028S-QZ for bug-gnu-emacs@gnu.org; Thu, 01 Nov 2018 19:08:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gIM4J-0000wS-L8 for bug-gnu-emacs@gnu.org; Thu, 01 Nov 2018 19:08:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54789) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gIM4H-0000wF-Uf for bug-gnu-emacs@gnu.org; Thu, 01 Nov 2018 19:08:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gIM4H-0000hz-L3 for bug-gnu-emacs@gnu.org; Thu, 01 Nov 2018 19:08:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gemini Lasswell Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Nov 2018 23:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33201 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33201-submit@debbugs.gnu.org id=B33201.15411136282656 (code B ref 33201); Thu, 01 Nov 2018 23:08:01 +0000 Original-Received: (at 33201) by debbugs.gnu.org; 1 Nov 2018 23:07:08 +0000 Original-Received: from localhost ([127.0.0.1]:59047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gIM3Q-0000gl-3J for submit@debbugs.gnu.org; Thu, 01 Nov 2018 19:07:08 -0400 Original-Received: from aibo.runbox.com ([91.220.196.211]:54544) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gIM3M-0000gb-Pg for 33201@debbugs.gnu.org; Thu, 01 Nov 2018 19:07:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From; bh=GgsWDAMZmeh481Ug+r5ssWJCxVAzB0i4gU08+gF8OzY=; b=IwfnrQNmkoQLI1rcZV43x3eKNw NTDYVN5e6EvGy1ehCbpd94TMBcxk2xqQO37i2R/jdLxcjJhnpmLqJnOFOAz/oGUB4E/FppRPgq9Yx c4OiQh4Z8QBHRnEgUmfI4lBadB1aQLxNn9UhorRjHW64g5PaozIHraQaka4iKmgOLH1NvHVln4k7h Mz6NoyN2kOLGDYxGtRpQ4a59DkwmY2UzNsgpIQYIBIjE4YlWtGrFtqYMyqjnA9lWsM3YTHuMgo+wY OW+Ti3DNhW6RAvuYFrDfXfo/oQzKU4Ak9y4T2nH3THZ/Xws/I2ZuGkrZ4tOlIxqTAB6WFjigTkmb+ uUGyNUmQ==; Original-Received: from [10.9.9.211] (helo=mailfront11.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1gIM3L-00075l-5W; Fri, 02 Nov 2018 00:07:03 +0100 Original-Received: by mailfront11.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1gIM2Z-0008HZ-Gs; Fri, 02 Nov 2018 00:06:16 +0100 In-Reply-To: <83bm78h7q7.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 01 Nov 2018 22:18:40 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:151928 Archived-At: Eli Zaretskii writes: >> From: Alan Mackenzie >> It seems like in Emacs 26.1 edebug can't be reliably used with >> edebug-unwrap-results non-nil because there's always a chance it will >> encounter the symbol `closure', at which point it errors out. >> [`closure' is wierd, because it has a meaning, yet has none of a >> function, a value, a property list.] > > I understand, but why does this make it a "major" problem? The only > major problem in Edebug I could understand is if Edebug could not be > used at all in some popular situation. FWIW, I never set > edebug-unwrap-results non-nil, and I'm a happy "Edebugger". > I agree with Eli that this is not a major problem. I suggest we close it as fixed in 27.1. Allen, unless you are doing the kind of debugging described in the docstring for 'edebug-unwrap-results', meaning debugging a macro where the results of expressions might include Edebug instrumentation, just leave it set to nil. Even if you are doing that kind of debugging, first try it without setting 'edebug-unwrap-results' non-nil, because if things are going wrong with the Edebug instrumentation because the debug spec for the macro is incorrect, which is the most common problem with Edebug and macros, then having Edebug unwrap the results will make it harder to figure out what the bug is. >> > I can: it's quite complex, and even includes gratuitous refactoring of >> > 'cond' as 'pcase'. When I have to dig several levels deep in a Lisp expression, I prefer to use pcase instead of expressions like "(nthcdr 2 (nth 1 (nth 3 sexp)))" but I can see that it is a matter of taste. >> OK. How about me doing a simpler, but less lazy fix which would just >> add handling of `closure' into the existing cond form? > > That's one thing; the other is why do we need to change edebug-unwrap1 > as well? AFAIU, that takes care of a separate issue, right? The problem isn't only closures, it's that edebug-unwrap* in emacs-26 doesn't handle dotted forms. For example, evaluating: (edebug-unwrap* '(setq foo '(1 . 1))) or trying to step through this with Edebug with edebug-unwrap-results set non-nil: (defmacro my-macro (arg) (let ((foo '(1 . 1))) `(setq ,arg ',foo))) will result in: (wrong-type-argument listp 1) The reason I rewrote edebug-unwrap* was to make it robust enough to handle anything it might find in backtrace frames, including dotted forms and circular data structures, so that I could use it to make working *Backtrace* buffers for Edebug that defaulted to not showing the instrumentation but let you toggle its visibility. Making edebug-unwrap-results work in more situations was a side effect.