From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#65344: 28.2; Unable to Edebug cl-flet form which uses argument destructuring Date: Sat, 19 Aug 2023 10:08:24 +0200 Message-ID: References: <040fe8aa-7a15-762c-e710-eb85f997d329@gmail.com> <871qg1tghr.fsf@web.de> <012813c5-cfc3-7ba9-5e84-70d79c172e77@gmail.com> <87zg2oyjre.fsf@web.de> <8b7fc1c2-ae6c-b825-c772-38b18ddb67d6@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------xL2kPOghXElQev99ufrdkGr7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34697"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Cc: brandon.irizarry@gmail.com, Eli Zaretskii , 65344@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 19 10:09:07 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 1qXH18-0008pk-O8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Aug 2023 10:09:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXH15-0002ek-8S; Sat, 19 Aug 2023 04:09:03 -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 1qXH13-0002ec-PG for bug-gnu-emacs@gnu.org; Sat, 19 Aug 2023 04:09:01 -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 1qXH13-0002JY-Gk for bug-gnu-emacs@gnu.org; Sat, 19 Aug 2023 04:09:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qXH14-00049M-Bn for bug-gnu-emacs@gnu.org; Sat, 19 Aug 2023 04:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Aug 2023 08:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65344 X-GNU-PR-Package: emacs Original-Received: via spool by 65344-submit@debbugs.gnu.org id=B65344.169243251715916 (code B ref 65344); Sat, 19 Aug 2023 08:09:02 +0000 Original-Received: (at 65344) by debbugs.gnu.org; 19 Aug 2023 08:08:37 +0000 Original-Received: from localhost ([127.0.0.1]:49316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXH0e-00048e-Vx for submit@debbugs.gnu.org; Sat, 19 Aug 2023 04:08:37 -0400 Original-Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]:59614) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXH0c-00048P-M2 for 65344@debbugs.gnu.org; Sat, 19 Aug 2023 04:08:35 -0400 Original-Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-99c4923195dso208816966b.2 for <65344@debbugs.gnu.org>; Sat, 19 Aug 2023 01:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692432508; x=1693037308; h=in-reply-to:subject:references:cc:to:from:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=YvNsCc2Zymkvl1MKOXKTwswm8lKCGB7knMkKwiXUzd0=; b=MM1onKihbDBkJ6HXfQ8zIqRP7HaXX7AUZwWA7QK+VMR3t0c0wWf5kdY+THe6XyD3Lx 5JkBSXstOcg5a4dEqnjMf+8dBjqjhZn4VBomVqqbCsLP51TxWV5EW4N+H0HKDdXUw5Df vHhh1aD39FZLgrpq8M+JF1lT84JeliiJMqQll7TFS/DbIv1FC5EMWLWSxiUOY4jmspJx xAZi+D29XpQjppJLFxgIgXnzTN9nllvFjuHCpe8tTGQ5Fuirl04re7TZpfY9VqltwYWA ynCvCcZzhZFsN24q8WgpXuX7Xm+jrptQWQlMtH0cm9qYc/5yWRortX/BqkHKLM+QCZmH tjFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692432508; x=1693037308; h=in-reply-to:subject:references:cc:to:from:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=YvNsCc2Zymkvl1MKOXKTwswm8lKCGB7knMkKwiXUzd0=; b=fxV/PYJWejtb02M4wrikUaqKLVMZAMw48NhGDzleNFd65YgaahheIgwLO/R3ZCNP2H Tn1BswrMsRdeOLd2iRSKAKZHDxfuIvbdlOSp6aycAkABFr+kztCV3gcoaRIWw7e66t1G MB5MEFiq9vP+qic3B/AdWfXGTDQZBrfSmqCGx0odkSkvRTIiqEewc9n+YFKKQeRCzAeJ YLAgyU08sSLOB9RP+pAzZ364AdysVPYlxjxXUzjTsHd3eDdNnStkL1/KENeTz5dqRpzZ lgoo/iWBiqaupburnJqhfpztHEWYuDnmdrvcmreFntSkS50sX8iYkF+dOZVL5UooRFnE q2Cw== X-Gm-Message-State: AOJu0YxDzK0iZ/I4Is1oGS5jXDrp4G03iYfr+g7aODjJEN2dwxQ+CnYB GtIgHHjS24K/5I4Q2FkmMOY= X-Google-Smtp-Source: AGHT+IH0X300pfLT/x3XVT5ecp09tqFLF5yNArq4KNEnkKtUSkWHMjzEzhf39079vHAFg3DazCmjsA== X-Received: by 2002:a17:906:1dd:b0:99b:dd1d:bc58 with SMTP id 29-20020a17090601dd00b0099bdd1dbc58mr1211587ejj.41.1692432507609; Sat, 19 Aug 2023 01:08:27 -0700 (PDT) Original-Received: from [192.168.178.21] (pd9e3670a.dip0.t-ipconnect.de. [217.227.103.10]) by smtp.gmail.com with ESMTPSA id m18-20020a1709061ed200b00988dbbd1f7esm2269042ejj.213.2023.08.19.01.08.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Aug 2023 01:08:26 -0700 (PDT) Content-Language: en-US In-Reply-To: <8b7fc1c2-ae6c-b825-c772-38b18ddb67d6@gmail.com> 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:267823 Archived-At: This is a multi-part message in MIME format. --------------xL2kPOghXElQev99ufrdkGr7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 18.08.23 08:43, Gerd Möllmann wrote: > On 18.08.23 07:58, Michael Heerdegen wrote: >> Gerd Möllmann writes: >> >>> which I would naively expect to be suitable for a single function in >>> an flet/labels.  (Maybe without the (setf ...) case, I'm not sure >>> ATM). >> >> That's correct, but only one part. > > RIght, that's what I meant. > >>> Do you perhaps have an insight why there are two &name in the flet >>> spec? >> >> Eh - not really.  That's some internal magic - to correctly associate >> the code with the function names or something like that, I guess. > > Ok. It's probably not important. > >>> Also naively asked, what does the &or in the flet case mean?  Does it >>> say that that the elements of the flet can either be symbols or >>> functions? >> >> There is a second syntax to support: a function binding can also have >> the syntax (fname EXPR) instead of (fname args body...).  EXPR can be a >> lambda expression but also any arbitrary Lisp returning a function >> value. > > (Another nominee for the most obscure feature of the month.  That's also > not in CL, BTW.) > > When I try something like > > (cl-flet (y (x (lambda () 1))) >   (x)) > > I get a not-a-list error from the Y.  That's kind of what I'm wondering. >  The debug declaratino for flet has the symbolp at the same level as > the local-function &define. > > And, if that's the problem, the next question would then be how to > declare a binding (FN VALUE).  Maybe (%define &name ... )? The Elisp manual has very nice description of debug specs, indeed. It's under Elisp > Edebug > Edebug and Macros > Specification Lists. From that description, I think this is the right debug spec for flet (patch attached) (debug ((&rest [&or (&define [&name symbolp "@cl-flet@"] [&name [] gensym] ;Make it unique! cl-lambda-list cl-declarations-or-string [&optional ("interactive" interactive)] def-body) (&define [&name symbolp "@cl-flet@"] [&name [] gensym] ;Make it unique! def-body)]) The second &define is for the (FN EXPR) bindings. It comes after the &define for "normal" function bindings because because, for some reason, apparently the second &define also matches the other case. (The description in the Elisp manual, BTW, also explain what the duplicate name does, although I'm not sure why it is done here, because the names of the local functions should be unique already. I'm probably overlooking something.) Seems to work for me. WDYT? --------------xL2kPOghXElQev99ufrdkGr7 Content-Type: text/plain; charset=UTF-8; name="flet.patch" Content-Disposition: attachment; filename="flet.patch" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvZW1hY3MtbGlzcC9jbC1tYWNzLmVsIGIvbGlzcC9lbWFjcy1s aXNwL2NsLW1hY3MuZWwKaW5kZXggMGEzMTgxNTYxYmQuLjBkOTFmNzcyNTFlIDEwMDY0NAot LS0gYS9saXNwL2VtYWNzLWxpc3AvY2wtbWFjcy5lbAorKysgYi9saXNwL2VtYWNzLWxpc3Av Y2wtbWFjcy5lbApAQCAtMjA2NCwxMiArMjA2NCwxNCBAQCBjbC1mbGV0CiAKIFwoZm4gKChG VU5DIEFSR0xJU1QgQk9EWS4uLikgLi4uKSBGT1JNLi4uKSIKICAgKGRlY2xhcmUgKGluZGVu dCAxKQotICAgICAgICAgICAoZGVidWcgKCgmcmVzdCBbJm9yIChzeW1ib2xwIGZvcm0pCi0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCZkZWZpbmUgWyZuYW1lIHN5bWJvbHAg IkBjbC1mbGV0QCJdCisgICAgICAgICAgIChkZWJ1ZyAoKCZyZXN0IFsmb3IgKCZkZWZpbmUg WyZuYW1lIHN5bWJvbHAgIkBjbC1mbGV0QCJdCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgWyZuYW1lIFtdIGdlbnN5bV0gO01ha2UgaXQgdW5pcXVlIQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNsLWxhbWJkYS1saXN0CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2wtZGVjbGFyYXRpb25z LW9yLXN0cmluZwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsm b3B0aW9uYWwgKCJpbnRlcmFjdGl2ZSIgaW50ZXJhY3RpdmUpXQorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGRlZi1ib2R5KQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICgmZGVmaW5lIFsmbmFtZSBzeW1ib2xwICJAY2wtZmxldEAiXQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsmbmFtZSBbXSBnZW5zeW1d IDtNYWtlIGl0IHVuaXF1ZSEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBkZWYtYm9keSldKQogICAgICAgICAgICAgICAgICAgIGNsLWRlY2xhcmF0aW9ucyBi b2R5KSkpCiAgIChsZXQgKChiaW5kcyAoKSkgKG5ld2VudiBtYWNyb2V4cGFuZC1hbGwtZW52 aXJvbm1lbnQpKQo= --------------xL2kPOghXElQev99ufrdkGr7--