From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#65620: void function edebug-after Date: Sun, 03 Sep 2023 06:29:29 +0200 Message-ID: <87v8cr3mmu.fsf@web.de> References: <87ledsku08.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10295"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , 65620@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 03 06:30:21 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qcekf-0002WJ-CM for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 03 Sep 2023 06:30:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qcekI-0001tm-7U; Sun, 03 Sep 2023 00:29:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qcekE-0001tY-6b for bug-gnu-emacs@gnu.org; Sun, 03 Sep 2023 00:29:55 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qcekD-0006Fx-36 for bug-gnu-emacs@gnu.org; Sun, 03 Sep 2023 00:29:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qcekM-0004d4-PE for bug-gnu-emacs@gnu.org; Sun, 03 Sep 2023 00:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Sep 2023 04:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65620 X-GNU-PR-Package: emacs Original-Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.169371539317752 (code B ref 65620); Sun, 03 Sep 2023 04:30:02 +0000 Original-Received: (at 65620) by debbugs.gnu.org; 3 Sep 2023 04:29:53 +0000 Original-Received: from localhost ([127.0.0.1]:39047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcekC-0004cG-UH for submit@debbugs.gnu.org; Sun, 03 Sep 2023 00:29:53 -0400 Original-Received: from mout.web.de ([212.227.17.12]:60855) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcekA-0004c0-0o for 65620@debbugs.gnu.org; Sun, 03 Sep 2023 00:29:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1693715370; x=1694320170; i=michael_heerdegen@web.de; bh=7HxV5k5j/STCx/cs+s3QpaVfVwyIJRPpfZgmQh9LDlg=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=frHsEuqJ2cLatcYeJ24N/lhOfBQ53RK8Iainq0gddlOcC5KmnuIqF4+hr1xFTLnR3mKeVMf as2Aew7AFmYToAuLQEEw06W9DMfLsVezuqcfHKkwc2cji6ehVamij00j1KqIdmkhiBVGTW09D 0LE1O8B5iaYvEZBVcKCw/iGXDsvdFbJNuWiZk87Um4J8F3gT3ftaIdgWryn5jBARTQqjd0UVm /wrn/jvC5Hh/8uVqr0GYFR1MvHxShEwsfgd/QpIw7rLvW+TjuoEEc8gFRnIGaZyT37G8eD4Mu smJijHrqoZ6SX4c6o+iuy0365lPVkvwsSFZYaKd7ztZS+ZGV12WA== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from drachen.dragon ([84.60.174.218]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1Mho0A-1pzDFy3IQK-00dpmb; Sun, 03 Sep 2023 06:29:30 +0200 In-Reply-To: (Alan Mackenzie's message of "Fri, 1 Sep 2023 21:27:12 +0000") X-Provags-ID: V03:K1:xttsuGsW5cCgEg23iH540ab2ekHHImeLY6z+0P1/0xln7mhk2Fb 0Sz75t6jR/caQ2kI5u+suijKf8ph8EB3PEAz9S57cydJvicOG0Rk19QtenWRmVhnYA8ty0I avtK9pTdY1fR7sL535Z+l2y3WwkTfbNhguM2FCtIMy8DwnMm8toRRv7/j492ao3CqWaFfgZ +jDnXV60YPbK99Ag/ax5g== UI-OutboundReport: notjunk:1;M01:P0:ceQD9eruvbw=;31WVJ3bGSghHIN5pKERWHlQkHjd S8AdN0NEd1ZbXW2p3ARxdoqhrCdwyRde9NASN76xpZ2/7FrcKnBkN2h48mLIxQ+KK7M2dkYsT 1oHNUNswhalF0PdG58B8Ze76uekLHwz9/atYeSkUKE0v3jqSxn8wLVx2FHoetrauaDg6/8JWi lT+PVtmO+0smlVHgAErmzR67kDbhBGkYkC4GXxIsdSnq4yRbU1q5DAJPrFTGS9Y59CcUH7VJo BO1m5QDbQow0Kzt/Tz7B+QvUy1jhUNfizVPGxeViEGfIJD+40SGkGsR/uwJjqRJcSyI71R0nb YpKDXj+noObEkXcUVZg4Crv/15Avzt7agtAyKGHFjVWBWCLiec3hQ5r98SKPglb/eFDsV5BYm UHzCfy0vGC86Ga2Kbw1LK29ijJ2+qg8Ee+3dtWRxcxBSMF85VekaIawi7TMDDNppd89hETAf+ +BUPONY8NOIotGws5LURidp8NaTvAuEn4Fj8jPezbrcj1cPsvy0K5qj5uV5KpE0W7kOB9A58v NYwDMZ/YiCaFMBI6x74jGMRXpTyLNsPqQS2RBexq+dcKB7MOOxzzY1skus2+PS1yc2ua0j798 6Ri5yDg5z0BG+abrskmyfRtN/MZnOJlX/DNGdw6skcTKTvK95cmUO4OLHt2T/UDiUy0HiI+3c cgEzxAiw/hmg/5Eqbq0/83qFMhikEuHPuJPg2vEQ3nW3FIzJbTHPoMEK095vPFUNlRDllOtkM 4x6GGx3LjqmJKxPy2gU0w00ZX2Lu9/UGm1ZcNoFFYQKyIWufisx6nfB1J0MSAj6o1FZtvF8I X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:269070 Archived-At: Hello Alan, > -(defalias 'edebug-before nil > +;; The following versions of `edebug-before' and `edebug-after' exist > +;; to handle the error which occurs if either of them gets called > +;; without an enclosing `edebug-enter'. This can happen, for example, > +;; when a macro mistakenly has a `form' element in its edebug spec, > +;; and it additionally, at macro-expansion time, calls `eval', > +;; `apply', or `funcall' (etc.) I wonder whether what you say about `apply', or `funcall' is true: What you can "call" in the macro expander is either a symbol or a function _form_, i.e., a quoted lambda. Maybe this quoted lambda is instrumented by Edebug when forcing it in the debug spec, dunno, but specifying a lambda expression in a macro call that is then called by the macro at expansion time as quoted lambda makes no sense, one would rather make the macro accept a form, or eval the function form in the expansion at run-time. So I'm not sure whether `apply' and `funcall' are really like `eval' in this case. Or - if the argument to funcall is a symbol - my question is what would happen when macro expansion calls instrumented functions the normal way (F . ARGS). This works correctly, right? Michael.