From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Aug 2023 12:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 65620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 65620@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16934002815550 (code B ref -1); Wed, 30 Aug 2023 12:59:02 +0000 Received: (at submit) by debbugs.gnu.org; 30 Aug 2023 12:58:01 +0000 Received: from localhost ([127.0.0.1]:52372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbKll-0001RK-Eh for submit@debbugs.gnu.org; Wed, 30 Aug 2023 08:58:01 -0400 Received: from lists.gnu.org ([2001:470:142::17]:36874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbKlc-0001Qi-Qh for submit@debbugs.gnu.org; Wed, 30 Aug 2023 08:57:56 -0400 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 1qbKlP-0004gn-LX for bug-gnu-emacs@gnu.org; Wed, 30 Aug 2023 08:57:39 -0400 Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbKlK-0005t3-Ih for bug-gnu-emacs@gnu.org; Wed, 30 Aug 2023 08:57:39 -0400 Received: (qmail 154 invoked by uid 3782); 30 Aug 2023 14:57:31 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=muc.de; i=@muc.de; q=dns/txt; s=default; t=1693400251; h=date : to : subject : message-id : mime-version : content-type : from : from; bh=s5tWaSE0Gh1coqY7X1jBKohyKJ3XfC4EN/0GIgKlJf4=; b=Lc8bOe2wXHh2sdfcSJdaHU1IwkSuTDcPDxSmc9/+ReIvDmXJ5b8LIVqLC7Y9FuTd/BE0R vcejKbLPkTzAiIwaoW/rXOKmlBF0OlfmA4HKL+s1s14HJYNwfh+o7nWlorMzsd3+HyeHx5+ /PEmgLZZLWbfndvIAgECTsgigmzZKtk2hWEI29g4S/f20AQYtiZn1nOrgo0idI+TyLQNGnS 3yNbQvZvscKsbqsqqVEnVbYbNSMzpQw6vWjO1H0mw17cSDn6ZZctEaVCxLEgdRXPiFqg7cX Dz4fWUdZxikQJ9Wo27HZt77m++aSwuMjoBFBKft/e3GoUGQ1B8aur6Vyf3PA== Received: from acm.muc.de (pd953a1ec.dip0.t-ipconnect.de [217.83.161.236]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 30 Aug 2023 14:57:30 +0200 Received: (qmail 26122 invoked by uid 1000); 30 Aug 2023 12:57:29 -0000 Date: Wed, 30 Aug 2023 12:57:29 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Hello, Emacs. On a recent master branch Emacs: (i) emacs -Q (ii) Insert the following into *scratch*: (defmacro hash-if (condition then-form &rest else-forms) "A conditional compilation macro analogous to C's #if. Evaluate CONDITION at macro-expansion time. If it is non-nil, expand the macro to THEN-FORM. Otherwise expand it to ELSE-FORMS enclosed in a `progn' form. ELSE-FORMS may be empty." (declare (indent 2) (debug (form sexp &rest sexp))) (if (eval condition lexical-binding) then-form (cons 'progn else-forms))) (defun foo (bar) (hash-if (< emacs-major-version 19) (car bar) (cons bar bar))) (iii) Evaluate hash-if by putting point after it and doing C-x C-e. (iv) Attempt to instrument foo for edebug by putting point inside foo and doing C-u C-M-x. This throws the error: "Ignoring macroexpansion error: (void-function edebug-after)". This attempt to evaluate edebug-after is a bug. -- Alan Mackenzie (Nuremberg, Germany). From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Aug 2023 23:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 65620@debbugs.gnu.org Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.16934369732766 (code B ref 65620); Wed, 30 Aug 2023 23:10:02 +0000 Received: (at 65620) by debbugs.gnu.org; 30 Aug 2023 23:09:33 +0000 Received: from localhost ([127.0.0.1]:54283 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbUJZ-0000iX-2f for submit@debbugs.gnu.org; Wed, 30 Aug 2023 19:09:33 -0400 Received: from mout.web.de ([212.227.17.11]:42235) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbUJU-0000iH-2D for 65620@debbugs.gnu.org; Wed, 30 Aug 2023 19:09:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1693436952; x=1694041752; i=michael_heerdegen@web.de; bh=3OYnHuf7+9RG84cHIV/42FkvWekb59+CDu8TbD9deZo=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=KzNDSBrQJnqn1KIpNHuPGqpZO0NHYwrb+9GNPtbrd1dvuec/WtlvRZ/p97gLS1Iazb5GW1u KIb0X5ene7tjcyAZGM1kgSZRiIHA0qDVhlZrB68yf58UJFlLPKCcLOdOe0SaFjxYBmILwUu8n 8pvkzqowA931i/I+Z6m/unS/yAQBe7w/7rASTWCd+T6CHEkC2CCIoFv1VkTgHRmQgIgc6uCKU k+szJZr2DhMxKyqT2MjTZ/r4zk1cWb1cG+fUNXgFrNilILGTvJ8kvDziR4CB2jxg8tsSAl3bM TZMOkFRxLmocBdzFj6iDCFaTGNJnC0t8rEf3NmvwFcxL9/oflxZw== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from drachen.dragon ([84.60.174.218]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1Mkmvd-1ppFnb07pv-00mMd8; Thu, 31 Aug 2023 01:09:12 +0200 From: Michael Heerdegen In-Reply-To: (Alan Mackenzie's message of "Wed, 30 Aug 2023 12:57:29 +0000") References: Date: Thu, 31 Aug 2023 01:09:11 +0200 Message-ID: <87ledsku08.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:JfzrWjgpVyWPlSeeze+Vv3kmkImn0UvJJG7tVhVS9inVNkOSdXe QfbVN+zlkMaEH9UdhQZE0MMm9llmx4uiIEsFcyna+JgoLewhCYGyPaJTy+snUAhQwuY+/Ku zt9qBuZWpReXbkddjn4yxWP2/Qkrz6oKUDapBuuLVmGPLD8a0ZDydUc1Z+n392d5/Fg3KLT PKsGUXpE9bALarGtEZZcw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:4QQQRWzahf8=;eeTfazc6BXolVm4mztvO2RjXyBW oyBOWRc0LYOqSV2QluHFl8vhwtqjiZyCq4HXG5azk5eoyWJYmz9v6b7lJA4njgjsRO9J3dhkJ PZpFe2W5wvO+nq4e6VoXrefDH89T0OYHwfsxKxLfFFAYo7LZzaQrqp6jhfo9YUKDkffuLyTN9 UAUE/gJw05eBTQ2J216yTI5WjZJ9Gkab9hD/3rZQwKfx7MrhHGqC2cL9LHG1zzk9FY8B735Zs 0iov2x0vyUE9NUaynOLaHwlXmlj9SnSLsoKuvzfnz4Pti4an5Vzk44cofqgXbj7zNPeXgEFu0 CDOVQYpC+qjTIAOah13GloHsUFMvdUIW7qnGzq4+OdAPJ5LXGWNqbTbi4s+X4qv0EHm1Zp9/6 ETNC37vzV4DrBkpngg2B6aQoTGujg4vLZLEnBKcqiiHJbUW6uSbL1nWiNnm6R5cAYIX1jbMZ8 y1hLtv0/RfJLY6Iu+FNUeyPkp2xXcQMPqmJBftBtip0SAAAxuI1jmPQ1SpQpfDZOLJpxZfVUm 4O/bUl8MFC549yj0lsu3CSqPUz4CD8kxoVCC/zjgqNKpGeDPOFXvR1gcpk/45ulPDJkL2u4WN qXeqtG0fGP30rickJ6CjGKZX5/w3U1FKkuEiyB4H5dXIIysWuBQb4h+lBITmAL5IuyTr1KTQ5 BQRIx2CopaFfZBrrLtzxhak8NzC+0hnji5FOcn5TbKp5pp/MSAESwyJAtnXmrLI2mRRLJq8Hq Nv9BnMI9+1KrJ0541WaKJa4tZzs45AyIYXHKfm0jq7OEviBgh48tBB1HSQnwo/m1p0z9aHoVX 679R36M989mRNPAHp8ceL/1ysMqTgU89JHOGQi5wCAWJs+b5GG/Y5/aJ2wImGKq61DrQjL6/6 m2ShK4p5NsQWQn7q18wnoTqtYaNwxWwny1Iotfwjw9E+Uu9RaeDp0xP1IpAzzP3aRngcL0x/n cme4g/2vCdpw1IXLyh76tazbL2M= X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: > (defmacro hash-if (condition then-form &rest else-forms) > "A conditional compilation macro analogous to C's #if. > Evaluate CONDITION at macro-expansion time. If it is non-nil, > expand the macro to THEN-FORM. Otherwise expand it to ELSE-FORMS > enclosed in a `progn' form. ELSE-FORMS may be empty." > (declare (indent 2) > (debug (form sexp &rest sexp))) > (if (eval condition lexical-binding) > then-form > (cons 'progn else-forms))) Dunno if someone is able to fix this (I'm not). Until then using `def-form` `or `sexp` instead of `form` works in a better way (the former edebugs CONDITION when instrumenting, the latter would omit edebugging the CONDITION entirely). Anyway, the key point in the above example is that macroexpanding (while instrumenting) combined with the `eval' call seems to lead to the evaluation of instrumented code outside of an Edebug session when CONDITION is instrumented using `form`. `eval-when-compile' uses `def-form` for example - I guess using `form` in this case doesn't work as one might expect. Michael. From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Aug 2023 07:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: Alan Mackenzie , 65620@debbugs.gnu.org Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.16934686671615 (code B ref 65620); Thu, 31 Aug 2023 07:58:01 +0000 Received: (at 65620) by debbugs.gnu.org; 31 Aug 2023 07:57:47 +0000 Received: from localhost ([127.0.0.1]:54802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbcYk-0000Py-Jy for submit@debbugs.gnu.org; Thu, 31 Aug 2023 03:57:46 -0400 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]:49248) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbcYi-0000Pa-KS for 65620@debbugs.gnu.org; Thu, 31 Aug 2023 03:57:45 -0400 Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-52bca2e8563so582910a12.2 for <65620@debbugs.gnu.org>; Thu, 31 Aug 2023 00:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693468650; x=1694073450; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=zg0Gw1q+oDm6bAx2+tluRvCGCHPrwOQjw/c6ddrjZYs=; b=UwBzL8TdbFedBXsVCsEOcdimM4yHlpthQ6UlU9aobxRGdMcMSbWbiMQsMyFUAj8xGR 1bIBUqKndq3n6UGik+2W0lmqez2fjF/A/+nNVkktGq9WutwhsaWqsmsarH1w3rscFNIN OP6BYV4EtP6fmlnOP5ngbRtwXUUGf7QCWF+l2mZzwLChjxZARxoB8NIRw17Fzz6lfyz5 ST4yjPBBJ28nFetyZr4BgBP2w/Jc1GOt22fPFPuq8dDcvbhhezAxHdxl5o5L3ATHkimn g3er8AJdAoRPBMLwtc8EYWkwV7jxsJSO2s6673psJdo9K+j0m2iuGkoOCRoUBLTukH0u TnYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693468650; x=1694073450; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zg0Gw1q+oDm6bAx2+tluRvCGCHPrwOQjw/c6ddrjZYs=; b=SqEI5NV5ApjH5b7lYRKY6Hhrv8ogRSI9tObj0sc5TNnEiKO49GDbtKqkWJwM1xKjCR +A2+sZgIiooinRcGyqi3JNxBX/LSgYwtFNkTzoXr82T8THLyK9lfCmEYV7kDnPDebaAA Rsonj/MRzYZDFw6JyzcPAOEmyQZqBw/iDQUeTU6rdTiFzS+wS6AXyO5bTcVYGIOjZXy5 +wbg1sahvXDlddDGwqIYt5gCHoKootnnlZ0QxymXYTzKj4eZW4maQhxNGY/eMOFgTlsO 06/8767rGX5qo8s3P8KmAWBJGSjk3l0MTc+AECUkLSOQ08fVhwMudgbFw67R5Zrxk3oa SmRA== X-Gm-Message-State: AOJu0Yxpwz2G3O6J7aw4SAF09lqLMfDNLjGXkoJP0hIKKzIXds2g4A7/ wIDdAP53VreRE3ZByzIxoGI0cEZJwU08anku X-Google-Smtp-Source: AGHT+IFOAZ8B7s1cbjNnQ5duaobxpF3Xg34UwvyYsrwEZljU+pVgq+uPe2Ll9YPhaP5FOZGIz5ZKug== X-Received: by 2002:a17:907:7758:b0:992:3897:1985 with SMTP id kx24-20020a170907775800b0099238971985mr3115180ejc.43.1693468650201; Thu, 31 Aug 2023 00:57:30 -0700 (PDT) Received: from Mini.fritz.box (pd9e36a8f.dip0.t-ipconnect.de. [217.227.106.143]) by smtp.gmail.com with ESMTPSA id a1-20020a17090682c100b009a1a653770bsm458414ejy.87.2023.08.31.00.55.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Aug 2023 00:56:21 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <87ledsku08.fsf@web.de> (Michael Heerdegen's message of "Thu, 31 Aug 2023 01:09:11 +0200") References: <87ledsku08.fsf@web.de> Date: Thu, 31 Aug 2023 09:55:18 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Michael Heerdegen writes: > Alan Mackenzie writes: > >> (defmacro hash-if (condition then-form &rest else-forms) >> "A conditional compilation macro analogous to C's #if. >> Evaluate CONDITION at macro-expansion time. If it is non-nil, >> expand the macro to THEN-FORM. Otherwise expand it to ELSE-FORMS >> enclosed in a `progn' form. ELSE-FORMS may be empty." >> (declare (indent 2) >> (debug (form sexp &rest sexp))) >> (if (eval condition lexical-binding) >> then-form >> (cons 'progn else-forms))) > > Dunno if someone is able to fix this (I'm not). Until then using > `def-form` `or `sexp` instead of `form` works in a better way (the > former edebugs CONDITION when instrumenting, the latter would omit > edebugging the CONDITION entirely). > > Anyway, the key point in the above example is that macroexpanding (while > instrumenting) combined with the `eval' call seems to lead to the > evaluation of instrumented code outside of an Edebug session when > CONDITION is instrumented using `form`. `eval-when-compile' uses > `def-form` for example - I guess using `form` in this case doesn't work > as one might expect. I think what's happening here is like this: By using 'form' for condition, we're telling edebug to instruments it. That is, the argument eval sees when foo is instrumented is whatever edebug wraps around the condition (< ...), and that contains the eval-after. Using sexp for the condition doesn't instrument the condition. One can follow that in the backtrace. So, I guess there's nothing to fix here. From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Aug 2023 08:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: Alan Mackenzie , 65620@debbugs.gnu.org Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.16934689972213 (code B ref 65620); Thu, 31 Aug 2023 08:04:02 +0000 Received: (at 65620) by debbugs.gnu.org; 31 Aug 2023 08:03:17 +0000 Received: from localhost ([127.0.0.1]:54806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbce5-0000Zc-E4 for submit@debbugs.gnu.org; Thu, 31 Aug 2023 04:03:17 -0400 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]:52578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbce1-0000ZG-DC for 65620@debbugs.gnu.org; Thu, 31 Aug 2023 04:03:16 -0400 Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-991c786369cso55823466b.1 for <65620@debbugs.gnu.org>; Thu, 31 Aug 2023 01:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693468979; x=1694073779; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=a8H/Qxet5Abn9WhxB3AcYREdnYRLqoZLEYWxwyOREao=; b=cSmMg7l/X+5Fv7XsCLUYyYCVQzb+63veqVJihEMDekGy4tvqWmfXKaQ9LUocwSn8oV Q8H7oCSg0YPLiRDKVNIjyRu20qjBiIMK8jrLpY5vj7Va9J5ohf8sOOtTPV+Pt7aaNPEM sMVU7F8cak97WBQVcnSMRQvnfzerpNi4W98Xn2JYvBImPO992m+ADlnMCsHmjRxKxzsu lIXwyL7ktUm7ZUkDGn/tZFL+8uo1dtGrs21ItJxADpumrNXYNs36R0yPBBGp5GjUWHu1 ziMWAN//CZ1rNLC4+DSDgkbNFIpYNOiHO56cDIXu2wQhG0Tb+40tD8dsQzyMbt2O7sZd g6aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693468979; x=1694073779; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=a8H/Qxet5Abn9WhxB3AcYREdnYRLqoZLEYWxwyOREao=; b=G/HDjNfeQtqrlodQSXgtxoJnAxlzmLPqLQTNTDojJpFJAgrppBj9RoLLnfxPHgidrr h0ZzK5BHrj0KdctE8reCtz+rooN4jIeAdLO8/1UD7IQE6SVVdDhle/qxKkJYv0qIFUu0 lQ8OqIDJe50bNOkPdKMgUA4sZ8/R8C2nWnvCMtlTaKfai/IqxxhOcMKk0UN1MM6GbtZv qmRF+TtHnxHJMGCX+7WB6SHRqkh0YZrlb1I9Srg7loTJq5BRfQ8FSuA2wMJqrBW4MaoQ eqZeQ402TBCYg6/Ogk3k/N/HxmrQdb/Xlgu9gQtMXmJSDfLJD7NX9yNvlaryxFUEOOgu 7FzA== X-Gm-Message-State: AOJu0YxT1KJUR9ucW51jDqHOgxcq9g9nupuOrMdt/Y5BumOIBcNEBjO+ Wo12lTJvznP0OwHs3/m+JOSzrE1+ZlJTFAxh X-Google-Smtp-Source: AGHT+IH8CeumLHbSGv/22JEd4ax2Hx2mywCPOowBarKRUXn7l3e/qTo8B0tYNC4AbN1PRX10Rgdlqw== X-Received: by 2002:a17:906:76c8:b0:9a1:d67c:b4eb with SMTP id q8-20020a17090676c800b009a1d67cb4ebmr3329665ejn.48.1693468978947; Thu, 31 Aug 2023 01:02:58 -0700 (PDT) Received: from Mini.fritz.box (pd9e36a8f.dip0.t-ipconnect.de. [217.227.106.143]) by smtp.gmail.com with ESMTPSA id dt22-20020a170906b79600b0099d959f9536sm479665ejb.12.2023.08.31.01.02.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Aug 2023 01:02:43 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: ("Gerd =?UTF-8?Q?M=C3=B6llmann?="'s message of "Thu, 31 Aug 2023 09:55:18 +0200") References: <87ledsku08.fsf@web.de> Date: Thu, 31 Aug 2023 10:02:18 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Michael Heerdegen writes: > >> Alan Mackenzie writes: >> >>> (defmacro hash-if (condition then-form &rest else-forms) >>> "A conditional compilation macro analogous to C's #if. >>> Evaluate CONDITION at macro-expansion time. If it is non-nil, >>> expand the macro to THEN-FORM. Otherwise expand it to ELSE-FORMS >>> enclosed in a `progn' form. ELSE-FORMS may be empty." >>> (declare (indent 2) >>> (debug (form sexp &rest sexp))) >>> (if (eval condition lexical-binding) >>> then-form >>> (cons 'progn else-forms))) >> >> Dunno if someone is able to fix this (I'm not). Until then using >> `def-form` `or `sexp` instead of `form` works in a better way (the >> former edebugs CONDITION when instrumenting, the latter would omit >> edebugging the CONDITION entirely). >> >> Anyway, the key point in the above example is that macroexpanding (while >> instrumenting) combined with the `eval' call seems to lead to the >> evaluation of instrumented code outside of an Edebug session when >> CONDITION is instrumented using `form`. `eval-when-compile' uses >> `def-form` for example - I guess using `form` in this case doesn't work >> as one might expect. > > I think what's happening here is like this: > > By using 'form' for condition, we're telling edebug to instruments it. > That is, the argument eval sees when foo is instrumented is whatever Sorry, "sees" is midleading: eval has as argument ... From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Aug 2023 13:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: Michael Heerdegen , acm@muc.de, 65620@debbugs.gnu.org Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.169348983024977 (code B ref 65620); Thu, 31 Aug 2023 13:51:01 +0000 Received: (at 65620) by debbugs.gnu.org; 31 Aug 2023 13:50:30 +0000 Received: from localhost ([127.0.0.1]:55205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbi45-0006Um-Nd for submit@debbugs.gnu.org; Thu, 31 Aug 2023 09:50:30 -0400 Received: from mail.muc.de ([193.149.48.3]:54170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbi43-0006UX-S9 for 65620@debbugs.gnu.org; Thu, 31 Aug 2023 09:50:29 -0400 Received: (qmail 60618 invoked by uid 3782); 31 Aug 2023 15:50:13 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=muc.de; i=@muc.de; q=dns/txt; s=default; t=1693489813; h=date : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to : from : from; bh=Fig1Ut55SScJdfC0aSae0mVw81enCzO/ZP3JVXQXtKg=; b=RS9Aws2SAL0CGKkpN4wAsC3KVSo/yBSMdwCDz1N3ysZx6hgF2aDy9yeY3mcyTjeniijkb 3e3CWmHzm9Nxsgg3/xWrSMKnumiC7+NWaNrA65ITPxpCDgAgkTAmuVLnOiBJ0I+XhwEydXH /M5BMTBduc/Yjg6LpyTAB4LDFgj+gbbD7FAmZIOe3VB+mAxfoXU9oIYlGYGZa5x84idrxtd 0alJpvpm1Mjors4FemXg6bvcoZtqpiXEQFcg0D58sc/H5t0bs7DvTNRNzjE40ZBY45IONGr 2eCUMzTo5EhqbRuIINzFiaM1VyFOAdYGL3cgjDGFgXje80lbTjD17yugGynQ== Received: from acm.muc.de (p4fe15975.dip0.t-ipconnect.de [79.225.89.117]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 31 Aug 2023 15:50:11 +0200 Received: (qmail 21562 invoked by uid 1000); 31 Aug 2023 13:50:11 -0000 Date: Thu, 31 Aug 2023 13:50:11 +0000 Message-ID: References: <87ledsku08.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Gerd. On Thu, Aug 31, 2023 at 09:55:18 +0200, Gerd Möllmann wrote: > Michael Heerdegen writes: > > Alan Mackenzie writes: > >> (defmacro hash-if (condition then-form &rest else-forms) > >> "A conditional compilation macro analogous to C's #if. > >> Evaluate CONDITION at macro-expansion time. If it is non-nil, > >> expand the macro to THEN-FORM. Otherwise expand it to ELSE-FORMS > >> enclosed in a `progn' form. ELSE-FORMS may be empty." > >> (declare (indent 2) > >> (debug (form sexp &rest sexp))) > >> (if (eval condition lexical-binding) > >> then-form > >> (cons 'progn else-forms))) > > Dunno if someone is able to fix this (I'm not). Until then using > > `def-form` `or `sexp` instead of `form` works in a better way (the > > former edebugs CONDITION when instrumenting, the latter would omit > > edebugging the CONDITION entirely). > > Anyway, the key point in the above example is that macroexpanding (while > > instrumenting) combined with the `eval' call seems to lead to the > > evaluation of instrumented code outside of an Edebug session when > > CONDITION is instrumented using `form`. `eval-when-compile' uses > > `def-form` for example - I guess using `form` in this case doesn't work > > as one might expect. > I think what's happening here is like this: > By using 'form' for condition, we're telling edebug to instruments it. > That is, the argument eval sees when foo is instrumented is whatever > edebug wraps around the condition (< ...), and that contains the > eval-after. Using sexp for the condition doesn't instrument the condition. Or, put a different way, edebug has instrumented CONDITION, then tries to evaluate this. This fails because there is no call to edebug-make-enter-wrapper around the thing, which would defalias edebug-after and edebug-before, and set up several lists that edebug needs. > One can follow that in the backtrace. > So, I guess there's nothing to fix here. I don't think I agree. eval (and probably apply and funcall and its variants) should somehow generate an "optional" edebug-make-enter-wrapper around them. This is currently not done. -- Alan Mackenzie (Nuremberg, Germany). From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Aug 2023 14:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Michael Heerdegen , 65620@debbugs.gnu.org Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.169349290031096 (code B ref 65620); Thu, 31 Aug 2023 14:42:01 +0000 Received: (at 65620) by debbugs.gnu.org; 31 Aug 2023 14:41:40 +0000 Received: from localhost ([127.0.0.1]:56734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbirc-00085T-5K for submit@debbugs.gnu.org; Thu, 31 Aug 2023 10:41:40 -0400 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]:62683) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbira-00085D-5m for 65620@debbugs.gnu.org; Thu, 31 Aug 2023 10:41:39 -0400 Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-51a52a7d859so4451507a12.0 for <65620@debbugs.gnu.org>; Thu, 31 Aug 2023 07:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693492884; x=1694097684; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0FslL1fwBIzd2a6T5M2RSknMwkw15CZbS0+RCC6+UUA=; b=g9z7xWcGw7At8iLNsmBEfJcDSKI26FKYGbSFcoPIj0hdy7WAI/ba+LFQRTK5nMu+1c UVZONYAcHk7XOwWINj0dqOtP4Id2rbrC6m+Gs1IYuhQBFWQtg+LPrpb6PSjty9JNrey4 ymAGuz3B1vtN2au8dzqQGg11R+UZI7rsgqgNu9wSdzHIpq61eFRqlSFLbYuMYNA+8Ecm /vVDPDodmZ2PyT5R21dsIpr+rcfLGyN4TAeHpFmyIy3h7zaRqEA4TzD8+Fp8cIAyuoZt kkPnNHVJq6qwJATBHyqoIrRqCXo/GYfVu969fcobq2TvEyJaRuZpqc9U6iPt4GTAqBSG wywg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693492884; x=1694097684; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0FslL1fwBIzd2a6T5M2RSknMwkw15CZbS0+RCC6+UUA=; b=ZSSrS+zKh12H0pXXDp9rrerD9eauPGZSZJHOlxDY9ypXPYvgBfKX0jtR/7uVJ12qUx 0WROVui0s+6jl24NFlneS99KLicNsszdRFx8rAkk0F1uphsSHnb05cc7QhLFGjIJ2N34 8Jz3twy7pOmdFakiyMaTs38li+szLmMXLT79oazUnY37rgV0GswKYmlzjcWVAlQZywfh tAzi1u1r7cm3aVjS8J/JV7BiAJZ+zYHSKX2jc9FkTTCEPPUR2A7dQmxgjUGPiynO0Dzz 835vDYVwOJzLJ61kOv5ks45/UgRrSPPS6UfJ1EmV5BM/gRBK5345apPpoWWYvVVhKjb4 XD+Q== X-Gm-Message-State: AOJu0YzppyQEc+5+soAYOYQOTHcqPo0WOIMp20el+/hehYq1QQKaCqMa WkcOvfSV/Bc73zcA+7vx7anOMisbHl8uYA== X-Google-Smtp-Source: AGHT+IF00jBYajJnxToKZspd6xwZvKHI7tQzCceesIR08sk444Fmp6xu+M/IaRMjPUZ++or6Sy0nCA== X-Received: by 2002:a17:906:30d2:b0:9a2:143e:a070 with SMTP id b18-20020a17090630d200b009a2143ea070mr2888248ejb.20.1693492883460; Thu, 31 Aug 2023 07:41:23 -0700 (PDT) Received: from Mini.fritz.box (pd9e36a8f.dip0.t-ipconnect.de. [217.227.106.143]) by smtp.gmail.com with ESMTPSA id jj17-20020a170907985100b009888aa1da11sm827585ejc.188.2023.08.31.07.41.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Aug 2023 07:41:22 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: (Alan Mackenzie's message of "Thu, 31 Aug 2023 13:50:11 +0000") References: <87ledsku08.fsf@web.de> Date: Thu, 31 Aug 2023 16:41:21 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: > Hello, Gerd. Hallo Alan, Gr=C3=BC=C3=9Fe nach N=C3=BCrnberg :-). > > On Thu, Aug 31, 2023 at 09:55:18 +0200, Gerd M=C3=B6llmann wrote: >> Michael Heerdegen writes: > >> > Alan Mackenzie writes: > >> >> (defmacro hash-if (condition then-form &rest else-forms) >> >> "A conditional compilation macro analogous to C's #if. >> >> Evaluate CONDITION at macro-expansion time. If it is non-nil, >> >> expand the macro to THEN-FORM. Otherwise expand it to ELSE-FORMS >> >> enclosed in a `progn' form. ELSE-FORMS may be empty." >> >> (declare (indent 2) >> >> (debug (form sexp &rest sexp))) >> >> (if (eval condition lexical-binding) >> >> then-form >> >> (cons 'progn else-forms))) > >> > Dunno if someone is able to fix this (I'm not). Until then using >> > `def-form` `or `sexp` instead of `form` works in a better way (the >> > former edebugs CONDITION when instrumenting, the latter would omit >> > edebugging the CONDITION entirely). > >> > Anyway, the key point in the above example is that macroexpanding (whi= le >> > instrumenting) combined with the `eval' call seems to lead to the >> > evaluation of instrumented code outside of an Edebug session when >> > CONDITION is instrumented using `form`. `eval-when-compile' uses >> > `def-form` for example - I guess using `form` in this case doesn't work >> > as one might expect. > >> I think what's happening here is like this: > >> By using 'form' for condition, we're telling edebug to instruments it. >> That is, the argument eval sees when foo is instrumented is whatever >> edebug wraps around the condition (< ...), and that contains the >> eval-after. Using sexp for the condition doesn't instrument the conditi= on. > > Or, put a different way, edebug has instrumented CONDITION, then tries to > evaluate this. This fails because there is no call to > edebug-make-enter-wrapper around the thing, which would defalias > edebug-after and edebug-before, and set up several lists that edebug > needs. I think that's correct, but I wouldn't say Edebug evaluates CONDITION, but we probably mean the same thing: CONDITION is instrumented and HASH-IF then gets that as argument when FOO is macroexpanded. Then the execution of HASH-IF tries to evaluate the instrumented condition etc. >> One can follow that in the backtrace. > >> So, I guess there's nothing to fix here. > > I don't think I agree. eval (and probably apply and funcall and its > variants) should somehow generate an "optional" edebug-make-enter-wrapper > around them. This is currently not done. That would be one way. On the other hand, the instrumentation of CONDITION is actually kind of pointless, because nothing will be left of it in the fully macroexpanded FOO. So, one cannot step through CONDITION with Edebug anyway. From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Sep 2023 09:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: Michael Heerdegen , acm@muc.de, 65620@debbugs.gnu.org Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.169356023831530 (code B ref 65620); Fri, 01 Sep 2023 09:24:01 +0000 Received: (at 65620) by debbugs.gnu.org; 1 Sep 2023 09:23:58 +0000 Received: from localhost ([127.0.0.1]:59860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc0Nh-0008CT-Cs for submit@debbugs.gnu.org; Fri, 01 Sep 2023 05:23:57 -0400 Received: from mail.muc.de ([193.149.48.3]:64659) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc0Nd-0008CC-Kc for 65620@debbugs.gnu.org; Fri, 01 Sep 2023 05:23:55 -0400 Received: (qmail 27966 invoked by uid 3782); 1 Sep 2023 11:23:37 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=muc.de; i=@muc.de; q=dns/txt; s=default; t=1693560217; h=date : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to : from : from; bh=+E03Z3uD017RkyjYW/PW2idHbSC0Id9wqmS5gwemhxk=; b=HGv/Ucc5E+Q4h191ST2R6zcsXQkmSw0n+9ZSxX3h+dtHVB+syQOxRNZZMfo/O1jd41Eey 3rBH91cxKw9GZ1eHW7twbdEHBp3UrZKtl3JIe065ByupgtnIj0uCp640H+3D6GMLUuH7oaP uU3Pr9rmPY0dUNAdoM/4+aHFmQpZsdnFLIrgXlovBJR6W6OOCFe3qxvrERgpeihms+5Aurs nyT0P5IQ0aYAY0mmIzAiy2Yx+5Pd/XdLZ+XPk5ktQUw3/j1EW91fMJMO1B5ukDUR/AVELMe v6C5hkWS/q3A9Q29+EDzSgKMKuwkfi+6+nauxIyYnBslH6ttGtNAlG0gMiCg== Received: from acm.muc.de (pd953a051.dip0.t-ipconnect.de [217.83.160.81]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 01 Sep 2023 11:23:36 +0200 Received: (qmail 16310 invoked by uid 1000); 1 Sep 2023 09:23:35 -0000 Date: Fri, 1 Sep 2023 09:23:35 +0000 Message-ID: References: <87ledsku08.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hallo, Gerd, Grüß aus Nürnberg! On Thu, Aug 31, 2023 at 16:41:21 +0200, Gerd Möllmann wrote: > Alan Mackenzie writes: > Hallo Alan, Grüße nach Nürnberg :-). > > On Thu, Aug 31, 2023 at 09:55:18 +0200, Gerd Möllmann wrote: > >> Michael Heerdegen writes: > >> > Alan Mackenzie writes: > >> >> (defmacro hash-if (condition then-form &rest else-forms) > >> >> "A conditional compilation macro analogous to C's #if. > >> >> Evaluate CONDITION at macro-expansion time. If it is non-nil, > >> >> expand the macro to THEN-FORM. Otherwise expand it to ELSE-FORMS > >> >> enclosed in a `progn' form. ELSE-FORMS may be empty." > >> >> (declare (indent 2) > >> >> (debug (form sexp &rest sexp))) > >> >> (if (eval condition lexical-binding) > >> >> then-form > >> >> (cons 'progn else-forms))) > >> > Dunno if someone is able to fix this (I'm not). Until then using > >> > `def-form` `or `sexp` instead of `form` works in a better way (the > >> > former edebugs CONDITION when instrumenting, the latter would omit > >> > edebugging the CONDITION entirely). > >> > Anyway, the key point in the above example is that macroexpanding (while > >> > instrumenting) combined with the `eval' call seems to lead to the > >> > evaluation of instrumented code outside of an Edebug session when > >> > CONDITION is instrumented using `form`. `eval-when-compile' uses > >> > `def-form` for example - I guess using `form` in this case doesn't work > >> > as one might expect. > >> I think what's happening here is like this: > >> By using 'form' for condition, we're telling edebug to instruments it. > >> That is, the argument eval sees when foo is instrumented is whatever > >> edebug wraps around the condition (< ...), and that contains the > >> eval-after. Using sexp for the condition doesn't instrument the condition. > > Or, put a different way, edebug has instrumented CONDITION, then tries to > > evaluate this. This fails because there is no call to > > edebug-make-enter-wrapper around the thing, which would defalias > > edebug-after and edebug-before, and set up several lists that edebug > > needs. > I think that's correct, but I wouldn't say Edebug evaluates CONDITION, > but we probably mean the same thing: CONDITION is instrumented and > HASH-IF then gets that as argument when FOO is macroexpanded. Then the > execution of HASH-IF tries to evaluate the instrumented condition etc. I think I've got it, now. Considering that hash-if evaluates CONDITION, it is an error for edebug to evaluate CONDITION as an argument first; there would be a sort of "double evaluation". So I need to use sexp rather than form in the edebug spec, like Michael and you have been telling me all along. :-) > >> One can follow that in the backtrace. > >> So, I guess there's nothing to fix here. > > I don't think I agree. eval (and probably apply and funcall and its > > variants) should somehow generate an "optional" edebug-make-enter-wrapper > > around them. This is currently not done. > That would be one way. On the other hand, the instrumentation of > CONDITION is actually kind of pointless, because nothing will be > left of it in the fully macroexpanded FOO. So, one cannot step through > CONDITION with Edebug anyway. Yes. This is a shame, since it would be nice to step through CONDITION, particularly if it is complicated. I think a better way of handling this would be to have a "base function" for edebug-after (and for edebug-before), as opposed to the nil that each of these currently has. These functions would throw an error asking the user to check the edebug spec. Something like (untested): (defun edebug-after (before-index after-index form) "Version of `edebug-after' to call when edebug is not yet set up. This function gets temporarily replaced by a real function when edebug becomes active." (error "Invalid call to `edebug-after' for %S: Is your debug spec \ correct?" form)) .. What do you think? -- Alan Mackenzie (Nuremberg, Germany). From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Sep 2023 12:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Michael Heerdegen , 65620@debbugs.gnu.org Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.16935712825273 (code B ref 65620); Fri, 01 Sep 2023 12:29:02 +0000 Received: (at 65620) by debbugs.gnu.org; 1 Sep 2023 12:28:02 +0000 Received: from localhost ([127.0.0.1]:60002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc3Fq-0001Mv-F9 for submit@debbugs.gnu.org; Fri, 01 Sep 2023 08:28:02 -0400 Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]:42317) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc3Fn-0001MS-W9 for 65620@debbugs.gnu.org; Fri, 01 Sep 2023 08:28:00 -0400 Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-99c93638322so392454466b.1 for <65620@debbugs.gnu.org>; Fri, 01 Sep 2023 05:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693571264; x=1694176064; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7FgF5HJbstF/QNZoQMEz79yoAvwKotWbqBggJqoDCzA=; b=W5UjSttKvExhFbbK8JfYnxUwSsOgouxowazdexH4QDKgY6axP5NYtw/T4zdApHfo4i VKEyjHSEoZ2+Pn/gA7V0VvSOmJuhlKLP0HMdWfJqKjA8teDiXM578lxugpX67h6dpcJy /UbvR5pm7PPnXRN2ZYLYQCAS0gHmEoh2o56glQYU6lZoEmLeFGHMxrltoB+whj46kBt2 fKNMaFeEff67/z4FXsqxIIehgF9qhqxrsY36wJHR6YQ5E7/2pWUhSB9/jxldhQlpJHDS oGvbS1Bm+P4WDBYA8wXwnhmYYsTE8AbofNMzPyjSt6jZRTAc1T2qjPh4sDAeG9rq8f38 V5iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693571264; x=1694176064; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7FgF5HJbstF/QNZoQMEz79yoAvwKotWbqBggJqoDCzA=; b=eOeHynsP4siJY7jtDG+vAVaoCQUinPcuwqVR7WmIct5SEM6YFWeiBYXjSqFThzolcn /egTaej1mmUIphWtKCM4b3ZdNRygwa+1+SQmKO9j7Qxc1Z9S3Iteek4Mla9/w3VxRCql /eeiFBDKbpOheW4zZjgtlOGflhNk78JepWFB0Na1eaYwCa/oHSHj6MjSLhIbMpvxYzEn L3AdFI2ci8Hm2hj3+5faq8X3NcbBbwqym+IYK9RU9HGLXoKsUFKyeMXYPZ7OuH40EJMj fWoNLydkQx1iWeznR9IuksSLWv5GpX1nHOzRAie+/67rjee5VQ37YQk4R+AZcg6tmjiV nbAw== X-Gm-Message-State: AOJu0Yz2+CbaXJTN9H4rNJ/tGx+AJofMCpT5W8dxwiEJoqNTHhaEBLBj ULGSEhWy5iQdFAX14XDfkh4= X-Google-Smtp-Source: AGHT+IF1Nz48vDXFDbFngDOPOOCBllsq1z5Btb2VSxPbBDX9Do6PrKisCHYtvZYFl9gowk1t4Aikjw== X-Received: by 2002:a17:907:c204:b0:9a1:ee8c:7f3b with SMTP id ti4-20020a170907c20400b009a1ee8c7f3bmr4612541ejc.7.1693571264263; Fri, 01 Sep 2023 05:27:44 -0700 (PDT) Received: from [192.168.178.21] (pd9e36738.dip0.t-ipconnect.de. [217.227.103.56]) by smtp.gmail.com with ESMTPSA id z15-20020a17090655cf00b0098dfec235ccsm1921193ejp.47.2023.09.01.05.27.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Sep 2023 05:27:43 -0700 (PDT) Message-ID: Date: Fri, 1 Sep 2023 14:27:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Content-Language: en-US References: <87ledsku08.fsf@web.de> From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.5 (----) On 01.09.23 11:23, Alan Mackenzie wrote: > I think a better way of handling this would be to have a "base function" > for edebug-after (and for edebug-before), as opposed to the nil that each > of these currently has. These functions would throw an error asking the > user to check the edebug spec. Something like (untested): > > (defun edebug-after (before-index after-index form) > "Version of `edebug-after' to call when edebug is not yet set up. > This function gets temporarily replaced by a real function when > edebug becomes active." > (error "Invalid call to `edebug-after' for %S: Is your debug spec \ > correct?" form)) > > .. What do you think? I find that an excellent idea! The error "void function edebug-after" might indeed be considered a bit unhelpful by some :-). Haven't tested anything either, though... From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Sep 2023 21:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: Michael Heerdegen , acm@muc.de, 65620@debbugs.gnu.org Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.169360365412877 (code B ref 65620); Fri, 01 Sep 2023 21:28:02 +0000 Received: (at 65620) by debbugs.gnu.org; 1 Sep 2023 21:27:34 +0000 Received: from localhost ([127.0.0.1]:34302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcBfx-0003Lc-Dw for submit@debbugs.gnu.org; Fri, 01 Sep 2023 17:27:33 -0400 Received: from mail.muc.de ([193.149.48.3]:31161) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcBfu-0003LL-RP for 65620@debbugs.gnu.org; Fri, 01 Sep 2023 17:27:31 -0400 Received: (qmail 64823 invoked by uid 3782); 1 Sep 2023 23:27:14 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=muc.de; i=@muc.de; q=dns/txt; s=default; t=1693603634; h=date : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to : from : from; bh=dcBbCvk+5smHrTP3s8LRSvFuYg9oG5LpXWKbL+0cb4Q=; b=kVoX1oSKvSuggXTy3KZjC9NaLZkCKifaV3vr6d99nCoIqkBpDIhegWCtLstKKY18K053L K+jwNHvJDzIVc3M9SJkZF2n1ZF6PymgI/SsNGdzy+zovnQGksxJD/JrmLpqQ1bGq3/620/A BgYwygOgQYnTh0qcb3rr6EIM44X3Cn4LAzUvu+1oxhmMH7gRTPY+ukahNl0bR8VpneRmoOZ PhlJ7UYKe8Z/NMgRR9LNHekKB3Z7FYJqN+oBbI/n+3/MP/ECcFo+FQSTN9/8iX9UdgIv8dU qHbFkusfAYgE88YEgxtbehhxjH751k+lHWpmfbg4mtPjjePOmH5Q6pHgR8sA== Received: from acm.muc.de (pd953a051.dip0.t-ipconnect.de [217.83.160.81]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 01 Sep 2023 23:27:13 +0200 Received: (qmail 9561 invoked by uid 1000); 1 Sep 2023 21:27:12 -0000 Date: Fri, 1 Sep 2023 21:27:12 +0000 Message-ID: References: <87ledsku08.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Gerd. On Fri, Sep 01, 2023 at 14:27:42 +0200, Gerd Möllmann wrote: > On 01.09.23 11:23, Alan Mackenzie wrote: > > I think a better way of handling this would be to have a "base function" > > for edebug-after (and for edebug-before), as opposed to the nil that each > > of these currently has. These functions would throw an error asking the > > user to check the edebug spec. Something like (untested): > > > > (defun edebug-after (before-index after-index form) > > "Version of `edebug-after' to call when edebug is not yet set up. > > This function gets temporarily replaced by a real function when > > edebug becomes active." > > (error "Invalid call to `edebug-after' for %S: Is your debug spec \ > > correct?" form)) > > > > .. What do you think? > I find that an excellent idea! The error "void function edebug-after" > might indeed be considered a bit unhelpful by some :-). Haven't tested > anything either, though... Here's a working patch with a slight improvement: the error message identifies the macro suspected of having an erroneous edebug spec. diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el index 9a06807bcdc..a6153d599ac 100644 --- a/lisp/emacs-lisp/edebug.el +++ b/lisp/emacs-lisp/edebug.el @@ -2469,12 +2469,50 @@ edebug-run-fast (setf (cdr (assq 'edebug edebug-behavior-alist)) '(edebug-default-enter edebug-fast-before edebug-fast-after))) -(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.) on the corresponding argument. This +;; is intended to fix bug#65620. + +(defun edebug-b/a-error (func) + "Throw an error for an invalid call of FUNC. +FUNC is expected to be `edebug-before' or `edebug-after'." + (let (this-macro + (n 0) + bt-frame) + (while (and (setq bt-frame (backtrace-frame n)) + (not (and (car bt-frame) + (eq (cadr bt-frame) 'macroexpand-1)))) + (setq n (1+ n))) + (when bt-frame + (setq this-macro (caaddr bt-frame))) + + (error + (concat "Invalid call to `" (symbol-name func) "'" + (if this-macro + (concat ". Is the edebug spec for `" + (symbol-name this-macro) + "' correct?") + ""))))) + +(defun edebug-before (_before-index) "Function called by Edebug before a form is evaluated. -See `edebug-behavior-alist' for implementations.") -(defalias 'edebug-after nil +See `edebug-behavior-alist' for other implementations. This +version of `edebug-before' gets called when edebug is not yet set +up. `edebug-enter' binds the function cell to a real function +when edebug becomes active." + (edebug-b/a-error 'edebug-before)) + +(defun edebug-after (_before-index _after-index _form) "Function called by Edebug after a form is evaluated. -See `edebug-behavior-alist' for implementations.") +See `edebug-behavior-alist' for other implementations. This +version of `edebug-after' gets called when edebug is not yet set +up. `edebug-enter' binds the function cell to a real function +when edebug becomes active." + (edebug-b/a-error 'edebug-after)) (defun edebug--update-coverage (after-index value) (let ((old-result (aref edebug-coverage after-index))) -- Alan Mackenzie (Nuremberg, Germany). From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Sep 2023 04:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Michael Heerdegen , 65620@debbugs.gnu.org Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.169362887219046 (code B ref 65620); Sat, 02 Sep 2023 04:28:02 +0000 Received: (at 65620) by debbugs.gnu.org; 2 Sep 2023 04:27:52 +0000 Received: from localhost ([127.0.0.1]:34778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcIEh-0004x7-QV for submit@debbugs.gnu.org; Sat, 02 Sep 2023 00:27:52 -0400 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]:42097) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcIEg-0004wu-75 for 65620@debbugs.gnu.org; Sat, 02 Sep 2023 00:27:51 -0400 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-99bc9e3cbf1so132913866b.0 for <65620@debbugs.gnu.org>; Fri, 01 Sep 2023 21:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693628854; x=1694233654; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=JT742VdbBe8/XhEd+O8ls8DcBuZ/cLbRWhOqEMsQuow=; b=G2y/GRJlFwwveudYq+Z/VyXAjycPyNfxFnjDba2+F934Uy4Y6YDrgHEt0YaDzYrc5I GSPEZSp84odVz4QcRHxmKV6hQJh+fgX7YMzFsC7YXPv7uL/pPfYkVH44bQ6oX/SL9knZ 05xUSgu61N+jub3EAjqpfeO2/wp9DNbc5XnQ3d+edpi9QctiB7AjHv2OUXVg+a6gh/gc eDqnBVFjK6MZ41p/gN5tx+iPc4sZLBE90Keeg6zsZAanOgyGVx48RGSk14mT++FYEQh7 VFTlVuu31MaWZC46C3wxlbjd8SGH1jk8m9ywTxocuElI4CMSM7Iv+5WBeo5yT/BxOTmL p+Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693628854; x=1694233654; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JT742VdbBe8/XhEd+O8ls8DcBuZ/cLbRWhOqEMsQuow=; b=hrjUxyyD8CKRrneeRxINoaQ8DxNcB5K7x4DnEyCO0ut6jsBx2sTHFCX/JumrBfix/u RXON+w4XjWfu5wwkkrl7/Un7kBsBqOLTFvNFzVDFLGd3ymkq9pRaGCiY8uk32/FFAZRK vmQAezwGaT7h8gvZXfgBlymsZ/iJBOUMvicTO0Ks/8xkui5aTe6KXdfm9+d6wGO2tFOi x0D0jgHvFSJrRjLKqPYEJS4oE6T0Vb3AMxoRkIUmBhJmTnJdZ7nQORUplX5RIiGFh6Al 35DplSBJpuasJtaa45E48QQ2J0qdkAgpl4T0ahfyP84hdF6gxcqwP5IRqy+dAaJ+Gv2s fk/Q== X-Gm-Message-State: AOJu0YzUi7KaUv1a1uaxBG+FsjwMqehjZ/th+a8hylXwNtOqvUwN2OKH atNfCnHrTyFo4bynjcVVx/x55T8rHhGgIw== X-Google-Smtp-Source: AGHT+IFNq15ltElv/tdRjrRLML/7GyVWqDSyMkHDtyYYroyCaqOafm0+xntS73hE2XoNcDF4siT/KQ== X-Received: by 2002:a17:907:6d02:b0:9a5:c38d:6b75 with SMTP id sa2-20020a1709076d0200b009a5c38d6b75mr8330579ejc.15.1693628854196; Fri, 01 Sep 2023 21:27:34 -0700 (PDT) Received: from Mini.fritz.box (pd9e362c0.dip0.t-ipconnect.de. [217.227.98.192]) by smtp.gmail.com with ESMTPSA id s23-20020a170906c31700b009934b1eb577sm2876262ejz.77.2023.09.01.21.27.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Sep 2023 21:27:33 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: (Alan Mackenzie's message of "Fri, 1 Sep 2023 21:27:12 +0000") References: <87ledsku08.fsf@web.de> Date: Sat, 02 Sep 2023 06:27:32 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: > Here's a working patch with a slight improvement: the error message > identifies the macro suspected of having an erroneous edebug spec. Maybe we could also add to the comment for edebug-before that basically any of the instrumented form in the context you describe can lead to errors? I believe, if IFORM is such an instrumented form, something like (let ((x IFORM)) ...) in some macro will also error. Otherwise, LGTM. Thanks for doing this! From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Sep 2023 13:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: Michael Heerdegen , 65620@debbugs.gnu.org Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.169366024426785 (code B ref 65620); Sat, 02 Sep 2023 13:11:02 +0000 Received: (at 65620) by debbugs.gnu.org; 2 Sep 2023 13:10:44 +0000 Received: from localhost ([127.0.0.1]:35435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcQOi-0006xw-Gb for submit@debbugs.gnu.org; Sat, 02 Sep 2023 09:10:44 -0400 Received: from mail.muc.de ([193.149.48.3]:59374) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcQOd-0006xf-NI for 65620@debbugs.gnu.org; Sat, 02 Sep 2023 09:10:43 -0400 Received: (qmail 64938 invoked by uid 3782); 2 Sep 2023 15:10:23 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=muc.de; i=@muc.de; q=dns/txt; s=default; t=1693660222; h=date : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to : from : from; bh=4t24a7WMNFMPJe6by92UaLJdDerGtXLYWb7G7Tz/1Gs=; b=RG4NXnS98mz32weRfrSXLZNuB5tFqNJpSoAZwlwvs8F/5B3I3df5RsHXsZEwgP6qTCCdN +cTYq6iSt/YS8eCU7bPVsHdLZPSLP3GWlM0dvVCMDxTFd69R9P1KhfDUQCXajHsLuIXd5JZ F0TkxiqrbBFoBs+Qe0453ZmoBX3YFvP6iDG2PjkoZTwrHBIiglI2WTztttuV4h2+RYhf5o+ 7oTiDH3ud78KY7TI/0TXIfZNPdlOlkybUmAgACN42ehRajD6L9UCJdnm9DJiJWXGBaEM40Y lFgpxeAmbecgsZcVcYbhYJqpqdt8Bnu68+89ZkLter1vYahYZCOEZWsdn4vw== Received: from acm.muc.de (p4fe15929.dip0.t-ipconnect.de [79.225.89.41]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 02 Sep 2023 15:10:21 +0200 Received: (qmail 7611 invoked by uid 1000); 2 Sep 2023 13:10:21 -0000 Date: Sat, 2 Sep 2023 13:10:21 +0000 Message-ID: References: <87ledsku08.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello again, Gerd. On Sat, Sep 02, 2023 at 06:27:32 +0200, Gerd Möllmann wrote: > Alan Mackenzie writes: > > Here's a working patch with a slight improvement: the error message > > identifies the macro suspected of having an erroneous edebug spec. > Maybe we could also add to the comment for edebug-before that basically > any of the instrumented form in the context you describe can lead to > errors? > I believe, if IFORM is such an instrumented form, something like > (let ((x IFORM)) > ...) > in some macro will also error. I've not been able to produce an error at macro-exansion time with a form like that. So I haven't amended that comment, yet. However, edebugging through a function which invoked such a macro can produce errors. This is all caused by having a `form' element in the edebug spec where there should be `sexp'. To try and ameliorate this, I propose adding a sentence to the description of `sexp' in doc/lispref/edebug.texi: diff --git a/doc/lispref/edebug.texi b/doc/lispref/edebug.texi index c5be3a40d2c..a64ebda6803 100644 --- a/doc/lispref/edebug.texi +++ b/doc/lispref/edebug.texi @@ -1289,6 +1289,8 @@ Specification List @item sexp A single unevaluated Lisp object, which is not instrumented. @c an "expression" is not necessarily intended for evaluation. +If the macro evaluates an argument at macro-expansion time, you should +use @code{sexp} for it, not @code{form}. @item form A single evaluated expression, which is instrumented. If your macro > Otherwise, LGTM. Thanks for doing this! Thanks! I'm seriously considering committing this soon. ;-) -- Alan Mackenzie (Nuremberg, Germany). From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Sep 2023 13:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Michael Heerdegen , 65620@debbugs.gnu.org Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.169366057627355 (code B ref 65620); Sat, 02 Sep 2023 13:17:02 +0000 Received: (at 65620) by debbugs.gnu.org; 2 Sep 2023 13:16:16 +0000 Received: from localhost ([127.0.0.1]:35448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcQU3-000778-L1 for submit@debbugs.gnu.org; Sat, 02 Sep 2023 09:16:15 -0400 Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]:50464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcQU1-00076i-ML for 65620@debbugs.gnu.org; Sat, 02 Sep 2023 09:16:14 -0400 Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-4ff8f2630e3so19765e87.1 for <65620@debbugs.gnu.org>; Sat, 02 Sep 2023 06:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693660557; x=1694265357; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9/Lv8mWc8w5jUvVBn/wW3/WrWQp5dzwwJl766QNfXZY=; b=fzJHIA3q76qybNKP4qRfRx1fBfEIEW9edYVtMpwCYne6yskX3Izf3pNhYsjpbeIFYo v26/5GRw0oaH1pWyi09DVh/ukgJYUrWjqDJNA8xIUi//sN0rm1CdN6NfaNh7I0392DQ1 SV63vGJxyn3mIU6z3C1WHwwbWJgzsFoeZDLvd5Gvcuq5luTYc8T6JCJNFALNltx6NCd/ yMWLlMaWA9lXYH5q5eo9q0dDvABlou3YGpgrGCu+uHc7AK3vJpqkrJ1438sRJnq1PAf0 TqUlQZt1MgFcl2h3MO0yYnpTwPUdtHuGuCbBfFPMixJqqupEKRlqVWYoIlvLbqOHNJbu Ii1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693660557; x=1694265357; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=9/Lv8mWc8w5jUvVBn/wW3/WrWQp5dzwwJl766QNfXZY=; b=TByS/KqrZgXuhwDGziXvLGAUehLjwtvscQPKw66I1wOcAPUvweliFbCsFS4yZ1hW+Q NLgBzc2iJpW1MNsMRzaTX/qE5l2ci5r6H5QdTBUGqWvyBpwxjzlAfD41GsT/dFOYIN88 2ysgN+BzTHonLi3rzWQ28NZJfGGXtl868KBix5awipDQ5hZEaNNjqwp229qpAaHnDmPd l0agPRrzL4QG5zCEe1vp42mpT8TxsNlbyM44HK1hGCIy0vXPdrBw7CKRGLmwYI35UrIp ie0rg93hFDgtWm16c+mzIYTcVEAfe1X1onyu9Usd728J/Qta6dwElnSFNCU31bNgsAHi IxGA== X-Gm-Message-State: AOJu0YxVnkylLdDlvymzx22I/0DMzniXuksBMG5Oqwj4elXDrKbXkpH9 +F/nz3S/9frIjtVPtpd/OG6L3AjjYnm6Rg== X-Google-Smtp-Source: AGHT+IHuLBtxwa/Gy3ljkyPjyhRTm/BlhGzlQoKA5EUjPTNB90enotg81HFvU3oHjyqYSz8LDc070A== X-Received: by 2002:a05:6512:2245:b0:4fb:8435:3efc with SMTP id i5-20020a056512224500b004fb84353efcmr4344563lfu.16.1693660557310; Sat, 02 Sep 2023 06:15:57 -0700 (PDT) Received: from Mini.fritz.box (pd9e362c0.dip0.t-ipconnect.de. [217.227.98.192]) by smtp.gmail.com with ESMTPSA id e23-20020aa7d7d7000000b00525683f9b2fsm3351237eds.5.2023.09.02.06.15.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Sep 2023 06:15:56 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: (Alan Mackenzie's message of "Sat, 2 Sep 2023 13:10:21 +0000") References: <87ledsku08.fsf@web.de> Date: Sat, 02 Sep 2023 15:15:55 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: > Hello again, Gerd. > > On Sat, Sep 02, 2023 at 06:27:32 +0200, Gerd M=C3=B6llmann wrote: >> Alan Mackenzie writes: > >> > Here's a working patch with a slight improvement: the error message >> > identifies the macro suspected of having an erroneous edebug spec. > >> Maybe we could also add to the comment for edebug-before that basically >> any of the instrumented form in the context you describe can lead to >> errors? > >> I believe, if IFORM is such an instrumented form, something like > >> (let ((x IFORM)) >> ...) > >> in some macro will also error.=20 > > I've not been able to produce an error at macro-exansion time with a > form like that.=20=20 Ok. > So I haven't amended that comment, yet. However, edebugging through a > function which invoked such a macro can produce errors. This is all > caused by having a `form' element in the edebug spec where there > should be `sexp'. > > To try and ameliorate this, I propose adding a sentence to the > description of `sexp' in doc/lispref/edebug.texi: > > > diff --git a/doc/lispref/edebug.texi b/doc/lispref/edebug.texi > index c5be3a40d2c..a64ebda6803 100644 > --- a/doc/lispref/edebug.texi > +++ b/doc/lispref/edebug.texi > @@ -1289,6 +1289,8 @@ Specification List > @item sexp > A single unevaluated Lisp object, which is not instrumented. > @c an "expression" is not necessarily intended for evaluation. > +If the macro evaluates an argument at macro-expansion time, you should > +use @code{sexp} for it, not @code{form}. >=20=20 > @item form > A single evaluated expression, which is instrumented. If your macro > Yes, that's helpful. From unknown Wed Jun 25 00:27:14 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Alan Mackenzie Subject: bug#65620: closed (Re: bug#65620: void function edebug-after) Message-ID: References: X-Gnu-PR-Message: they-closed 65620 X-Gnu-PR-Package: emacs Reply-To: 65620@debbugs.gnu.org Date: Sat, 02 Sep 2023 13:59:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1693663142-1642-1" This is a multi-part message in MIME format... ------------=_1693663142-1642-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #65620: void function edebug-after which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 65620@debbugs.gnu.org. --=20 65620: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D65620 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1693663142-1642-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 65620-done) by debbugs.gnu.org; 2 Sep 2023 13:58:04 +0000 Received: from localhost ([127.0.0.1]:38195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcR8U-0000PJ-Tn for submit@debbugs.gnu.org; Sat, 02 Sep 2023 09:58:04 -0400 Received: from mail.muc.de ([193.149.48.3]:60770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qcR8O-0000Om-QF for 65620-done@debbugs.gnu.org; Sat, 02 Sep 2023 09:58:01 -0400 Received: (qmail 18663 invoked by uid 3782); 2 Sep 2023 15:57:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=muc.de; i=@muc.de; q=dns/txt; s=default; t=1693663060; h=date : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to : from : from; bh=e94rEqWCU3Cgrq9cYJdnj4bFqS40BDiMJYHQHO6PonM=; b=CzAbW+zDjfRk6dFO0awoZShc7YNb1YM/+YpeJXsWUs1Zg+nTfZ17v6wyrUcYY2kpzHAFQ lnBF4AUr5BuCW6oULld9ptVF8UuWxOY7j2mpbVeTBSA2GsgqmHP+U4FxQzhA6IN8400PhoL 8X3geLTV6CRaH6UE6vde06g/UJNj2EB4gPm3foMMeFW5MmPrPE/niaDgW/J+BSp7cEzG3pL IqIE0i+bsXzMuYVcJ2gJGWNlXbj4JK58AhHtbPBenXhwzhuypEmvlkBwu0wSpKnpRz181aL Ag2sgPGITocw85g0GJPcqj5zEU1xZ2Qbc6HMCR8NaL5MgO9I/gRnEgFiEz5g== Received: from acm.muc.de (p4fe15929.dip0.t-ipconnect.de [79.225.89.41]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 02 Sep 2023 15:57:38 +0200 Received: (qmail 28516 invoked by uid 1000); 2 Sep 2023 13:57:38 -0000 Date: Sat, 2 Sep 2023 13:57:38 +0000 To: Gerd =?iso-8859-1?Q?M=F6llmann?= Subject: Re: bug#65620: void function edebug-after Message-ID: References: <87ledsku08.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65620-done Cc: Michael Heerdegen , acm@muc.de, 65620-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Gerd. On Sat, Sep 02, 2023 at 15:15:55 +0200, Gerd Möllmann wrote: > Alan Mackenzie writes: [ .... ] > > .... However, edebugging through a function which invoked such a > > macro can produce errors. This is all caused by having a `form' > > element in the edebug spec where there should be `sexp'. > > To try and ameliorate this, I propose adding a sentence to the > > description of `sexp' in doc/lispref/edebug.texi: > > diff --git a/doc/lispref/edebug.texi b/doc/lispref/edebug.texi > > index c5be3a40d2c..a64ebda6803 100644 > > --- a/doc/lispref/edebug.texi > > +++ b/doc/lispref/edebug.texi > > @@ -1289,6 +1289,8 @@ Specification List > > @item sexp > > A single unevaluated Lisp object, which is not instrumented. > > @c an "expression" is not necessarily intended for evaluation. > > +If the macro evaluates an argument at macro-expansion time, you should > > +use @code{sexp} for it, not @code{form}. > > @item form > > A single evaluated expression, which is instrumented. If your macro > Yes, that's helpful. Thanks! I've committed the patch to the two files, and I'm now closing the bug. -- Alan Mackenzie (Nuremberg, Germany). ------------=_1693663142-1642-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 30 Aug 2023 12:58:01 +0000 Received: from localhost ([127.0.0.1]:52372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbKll-0001RK-Eh for submit@debbugs.gnu.org; Wed, 30 Aug 2023 08:58:01 -0400 Received: from lists.gnu.org ([2001:470:142::17]:36874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbKlc-0001Qi-Qh for submit@debbugs.gnu.org; Wed, 30 Aug 2023 08:57:56 -0400 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 1qbKlP-0004gn-LX for bug-gnu-emacs@gnu.org; Wed, 30 Aug 2023 08:57:39 -0400 Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbKlK-0005t3-Ih for bug-gnu-emacs@gnu.org; Wed, 30 Aug 2023 08:57:39 -0400 Received: (qmail 154 invoked by uid 3782); 30 Aug 2023 14:57:31 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=muc.de; i=@muc.de; q=dns/txt; s=default; t=1693400251; h=date : to : subject : message-id : mime-version : content-type : from : from; bh=s5tWaSE0Gh1coqY7X1jBKohyKJ3XfC4EN/0GIgKlJf4=; b=Lc8bOe2wXHh2sdfcSJdaHU1IwkSuTDcPDxSmc9/+ReIvDmXJ5b8LIVqLC7Y9FuTd/BE0R vcejKbLPkTzAiIwaoW/rXOKmlBF0OlfmA4HKL+s1s14HJYNwfh+o7nWlorMzsd3+HyeHx5+ /PEmgLZZLWbfndvIAgECTsgigmzZKtk2hWEI29g4S/f20AQYtiZn1nOrgo0idI+TyLQNGnS 3yNbQvZvscKsbqsqqVEnVbYbNSMzpQw6vWjO1H0mw17cSDn6ZZctEaVCxLEgdRXPiFqg7cX Dz4fWUdZxikQJ9Wo27HZt77m++aSwuMjoBFBKft/e3GoUGQ1B8aur6Vyf3PA== Received: from acm.muc.de (pd953a1ec.dip0.t-ipconnect.de [217.83.161.236]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 30 Aug 2023 14:57:30 +0200 Received: (qmail 26122 invoked by uid 1000); 30 Aug 2023 12:57:29 -0000 Date: Wed, 30 Aug 2023 12:57:29 +0000 To: bug-gnu-emacs@gnu.org Subject: void function edebug-after Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Hello, Emacs. On a recent master branch Emacs: (i) emacs -Q (ii) Insert the following into *scratch*: (defmacro hash-if (condition then-form &rest else-forms) "A conditional compilation macro analogous to C's #if. Evaluate CONDITION at macro-expansion time. If it is non-nil, expand the macro to THEN-FORM. Otherwise expand it to ELSE-FORMS enclosed in a `progn' form. ELSE-FORMS may be empty." (declare (indent 2) (debug (form sexp &rest sexp))) (if (eval condition lexical-binding) then-form (cons 'progn else-forms))) (defun foo (bar) (hash-if (< emacs-major-version 19) (car bar) (cons bar bar))) (iii) Evaluate hash-if by putting point after it and doing C-x C-e. (iv) Attempt to instrument foo for edebug by putting point inside foo and doing C-u C-M-x. This throws the error: "Ignoring macroexpansion error: (void-function edebug-after)". This attempt to evaluate edebug-after is a bug. -- Alan Mackenzie (Nuremberg, Germany). ------------=_1693663142-1642-1-- From unknown Wed Jun 25 00:27:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65620: void function edebug-after 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 X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , 65620@debbugs.gnu.org Received: via spool by 65620-submit@debbugs.gnu.org id=B65620.169371539317752 (code B ref 65620); Sun, 03 Sep 2023 04:30:02 +0000 Received: (at 65620) by debbugs.gnu.org; 3 Sep 2023 04:29:53 +0000 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 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 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 From: Michael Heerdegen In-Reply-To: (Alan Mackenzie's message of "Fri, 1 Sep 2023 21:27:12 +0000") References: <87ledsku08.fsf@web.de> Date: Sun, 03 Sep 2023 06:29:29 +0200 Message-ID: <87v8cr3mmu.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:xttsuGsW5cCgEg23iH540ab2ekHHImeLY6z+0P1/0xln7mhk2Fb 0Sz75t6jR/caQ2kI5u+suijKf8ph8EB3PEAz9S57cydJvicOG0Rk19QtenWRmVhnYA8ty0I avtK9pTdY1fR7sL535Z+l2y3WwkTfbNhguM2FCtIMy8DwnMm8toRRv7/j492ao3CqWaFfgZ +jDnXV60YPbK99Ag/ax5g== X-Spam-Flag: NO 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/UGm1ZcNoFFYQKyIWufisx6nfB1J0MSAj6o1FZtvF8IY ItZhCS+/j/kSTOT3pcK9Ki7RreKooYTHSTvc3X2dWq/yInZX0gegRo/B9BEC2Jlb5Zuew+0mQ 3D/VJcQ1AQBNXsmTPlwQ/xdXWSAeqMhoYzJcSqfgyLAZm1roVkgtL9UMdlf2LZemzSHwjoh99 3fZjI/JCmo3FW0VOJdEJRVFbNWA= Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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.