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#65344: 28.2; Unable to Edebug cl-flet form which uses argument destructuring Date: Sat, 26 Aug 2023 02:16:02 +0200 Message-ID: <87sf868xq5.fsf@web.de> References: <87wmxqs0ti.fsf@web.de> <616b60fc-9f68-14ae-d262-716eb0cc685d@gmail.com> <87h6ot19av.fsf@web.de> <878ra3q4kk.fsf@web.de> <87il97obdi.fsf@web.de> <87edju4mzd.fsf@web.de> <87edjsghyf.fsf@web.de> <87il93kbn0.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26712"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , "brandon.irizarry@gmail.com" , Eli Zaretskii , "65344@debbugs.gnu.org" <65344@debbugs.gnu.org> To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 26 02:17:19 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 1qZgzO-0006jJ-RJ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 26 Aug 2023 02:17:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZgz5-0005HT-H6; Fri, 25 Aug 2023 20:16:59 -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 1qZgz4-0005HK-55 for bug-gnu-emacs@gnu.org; Fri, 25 Aug 2023 20:16:58 -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 1qZgz3-0001NM-TQ for bug-gnu-emacs@gnu.org; Fri, 25 Aug 2023 20:16:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qZgz8-0007Zn-Cz for bug-gnu-emacs@gnu.org; Fri, 25 Aug 2023 20:17: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: Sat, 26 Aug 2023 00:17: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.169300898229072 (code B ref 65344); Sat, 26 Aug 2023 00:17:02 +0000 Original-Received: (at 65344) by debbugs.gnu.org; 26 Aug 2023 00:16:22 +0000 Original-Received: from localhost ([127.0.0.1]:41250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZgyT-0007Yp-V8 for submit@debbugs.gnu.org; Fri, 25 Aug 2023 20:16:22 -0400 Original-Received: from mout.web.de ([217.72.192.78]:60655) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZgyR-0007Yb-3a for 65344@debbugs.gnu.org; Fri, 25 Aug 2023 20:16:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1693008963; x=1693613763; i=michael_heerdegen@web.de; bh=36ix3cVfbXrif14KW3kbsOZYm88NFwSgyF29sKmJZKM=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=oRd5U0f3cKks/JuynL2l9QU1NZa1g8qhlpqkggNlwo7rcyU1EClCpMKWN+1IEpM4V3foR6T vyj4zH1/A/7BU8Bd25Du4kl0SDjl8OZcxGMRtyuUWzNtdJENZmOUh3XVEewpgomlaw1OCcMvD ReUXpPrlPM6La6bW65k31KbTC7DCGzIcGTUR/dhe67PCfj363aqNks+kNsZpeL370KfWS0C5i GA0y6s2ihr98+Yaw9Y8DHY90Z3vuY1nXh/oBALilcOumUeNvFtGKAUB+MdWgQB0+tBOsbe0rS U9J5ECIMZjZXqegGJ5UIWcoEDKH9Z4yr3vPxZQfwzMCZZqSv/vDA== 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 1MrwsB-1px6dq2xSH-00o2W9; Sat, 26 Aug 2023 02:16:03 +0200 In-Reply-To: (Drew Adams's message of "Fri, 25 Aug 2023 14:50:57 +0000") X-Provags-ID: V03:K1:IcteTXpXFVWqILEWoPW3CsrxHyx9UC3C4fNhwQxydrFWk4Eze8A 0BfyTzIIhRblLzP0mOhfxKU1baCK3MxGCaYXMHbZllE0HqVfMBS/piPjyyEmo+2AKnmc64/ X3ErzRH5F9GHQm5FT6D/F7eDgoc3SqsnVPiTD7FvqXWWUbwEUv/IaQ9Kxg8kRwr4Z/dZvaq 4aRQWPPIM6XXT6VxaLgag== UI-OutboundReport: notjunk:1;M01:P0:G7r6QUcrJNE=;OQ80UDPG+AwZpKaa1GmSLbVDbc/ n1NaYf9tQDwpsdRksrI5TrunyuLb8Ts1fOgb+cORZczhjXE4Vjjrbj/yMxDr8cI8WWMXcvRZR 3XFlwnPdRijPJmxCEApJVE/xqPAxwnIaa/WzkKZeB5LL6ZGQrVZwvbRVxIgBRXBUGwev9EHsZ UdnPWVur2HkQPQ87eytckT9RUCAwIIc8ToMksx4qWDKTPM/5kEQ2u2WZ+oUBFofWEesu54SDk pkk5NiBbV6MhXPXkFx2s3di5Y4QJ+zTBCe5kr7xDAeYZ+lGNm3I49DSl2Bl00bXFJU9zcZvE+ eS64ffV4nMtIJeOP66fIq8MCB8Glv2wdToh6RXGh9QQXUxamqtk7xpj/841XOxmNvRg9N5e+e UndsmMkkLs3xkQ1m5SNTLRoev0MMecRZwHA5PxH3cIpa9vY7xjmPKGEWJc4S1dVTdV2NBVF+w 5o+/v/mlx6iccTzm2P+4+K1yeXAeOG0Zg3Enha84U1VBld/8/7ad80HDscd0bzQSEPIPiOnLY pEUTJfWGcqj8CVvMQrtVM4QiyCD+RcgQJvhsReRQMRLplhhjpm8m47Y2fQR+1+2x2XNnQiSiL YRXCp9LFPCkvLPryb9aOkfQ2EmbU3FzBuE6l5nxYSe66XeSiyrPcXCfHKls881kdjhWvxm/bv 8kpWs3bNHF6h5vxX7wiVPBVnxM+erdrBxb98/VccuXTBWTLnexodxVWeocMvzwcrRvm1993Sb nGwIi3A9MF8HMJgjonGgFv+IH3UOtbY9aEkW79J7YP+PIj9gEHz5NiwpTqJ+74qdFTKU66Vl 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:268452 Archived-At: Drew Adams writes: > OK, so you don't see a problem. Do you see > a reason why we would add some `cl-foobar' to > `cl-lib.el', if it's a function that has no > relation to Common Lisp? Does it make any > sense to you that someone might expect it to > be housed elsewhere, with a different prefix > (or with no prefix)? > > That's all I'm trying to say here. Let's avoid > stuffing non-CL stuff in `cl*.el' files. Is it > necessary to clean house wholesale, moving and > renaming things to fix this mixup? No. I'm > not proposing disruption or extra work - just a > recognition of a will to avoid adding not CL > stuff to `cl*.el' files and giving it prefix > `cl-'. Nothing revolutionary or heavy-handed > intended. Sorry about mentioning flet again, but it's a good example to discuss. Would you want that we have cl-flet, which is an restricted version of the current implementation, and cl-flet*, which is like the current cl-flet? Or two constructs with non-overlapping semantics? Or was extending cl-flet as had been done ok for you? Your suggestion sounds logical and objective, but what has "a relation to CL" or is "not CL" is a bit subjective, it is an individual decision where to draw the line. I mean, anyone could agree with your claim but some may still come to other decision than you would expect. Michael.