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: Thu, 24 Aug 2023 05:16:04 +0200 Message-ID: <87zg2hqgej.fsf@web.de> References: <012813c5-cfc3-7ba9-5e84-70d79c172e77@gmail.com> <87zg2oyjre.fsf@web.de> <8b7fc1c2-ae6c-b825-c772-38b18ddb67d6@gmail.com> <877cpqs6vi.fsf@web.de> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24855"; 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 Thu Aug 24 05:17:20 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 1qZ0qV-0006CE-KB for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Aug 2023 05:17:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZ0qC-0006nF-Tt; Wed, 23 Aug 2023 23:17:00 -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 1qZ0qA-0006mt-MK for bug-gnu-emacs@gnu.org; Wed, 23 Aug 2023 23: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 1qZ0qA-00082F-EV for bug-gnu-emacs@gnu.org; Wed, 23 Aug 2023 23:16:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qZ0qD-0002sQ-RM for bug-gnu-emacs@gnu.org; Wed, 23 Aug 2023 23:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Aug 2023 03:17:01 +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.169284698411008 (code B ref 65344); Thu, 24 Aug 2023 03:17:01 +0000 Original-Received: (at 65344) by debbugs.gnu.org; 24 Aug 2023 03:16:24 +0000 Original-Received: from localhost ([127.0.0.1]:35738 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ0pc-0002rT-5v for submit@debbugs.gnu.org; Wed, 23 Aug 2023 23:16:24 -0400 Original-Received: from mout.web.de ([212.227.15.4]:52271) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ0pX-0002r8-2C for 65344@debbugs.gnu.org; Wed, 23 Aug 2023 23:16:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1692846965; x=1693451765; i=michael_heerdegen@web.de; bh=B5ibj+p8mMv124UISUd+8hDkrdhebbsGLjYTPbyLGak=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=vCNaBMtDqRMrJA71LoV7OTsDxPgPf8EflPCttHyHcqyRUzwDkmwxZt6YL2+zJG7gqA44NpI KFumDNgAPFb4bJbeda2gN/HTfgej3UB9lhdVRLS1kwpa3wipIDCIPl+So1r8hz/zEEqW9YGGj 0TbuC8vO+f1jYO/9HD1qUxJPGLbQF8fHsgNQ/UY8VAsH/8XWkssjgMyxHMtxnIr+F1mPPk5D0 c4ENhOeR2euI1WOEn5tQ/GCHqXizlSQgREs0jR73JshK8dTX4RQj1m7Z0tC2j3ERhp4lD4A7a lhhWNkGdPELUeZFnJazpfTyo46AbNQxIHj6L4ZfO81M/VUqfBvqg== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from drachen.dragon ([84.60.174.218]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1My6pf-1pnFBy1m4l-00zMAy; Thu, 24 Aug 2023 05:16:05 +0200 In-Reply-To: (Drew Adams's message of "Wed, 23 Aug 2023 14:23:29 +0000") X-Provags-ID: V03:K1:fXXn6/wSw7dbxcp+PszcXs4xLSkSe96TJO+1/KfrzlLol+FGqRT OQUzml2V4thzBxulgco5ualH/n12rOodptQRcyUv/+HRBRDDrJ5awr7NJYRxOJk98D4td3T ae+vtlChJGVewzrel6LGIOQgtqV7UcXZZO9up0ovQfKQCyR5TUjbEsoBv2IyyqwOfC5v5h+ WXReQ+0KJA3bp7QS/QZgg== UI-OutboundReport: notjunk:1;M01:P0:7Cu1rBt+8KE=;nz7o2YRa/P++UQRlYAzcZXMiHsL iaM02k1nzDpCNQx5zkKyhNIEy1GMsJAny6pYrUUILMobQNsHA39PgMGx+VoogoW0oE1vZRp+9 J5Fg0wA1GjPTcvoNmBSC7J93QrQ3CX3Ks+uyIecGwaeyam4Q/WQgtCMrPh5GI5Lp/RbSEHmBE atIz6BaTFseSD72PvjMPlvxsjlhaxqFlzUBrjNhGz2psiGZlabaGMvoyZcqHMFxZ4lo0UhpJL FfBPmtNPZwHNiQAmcJzm9OQcs76kQtnZaGO9THBsqvHVjUTHkjpELNg9OC/Rlwz6VfR07cQV+ LEcgRJP3MK0viXg2FwN+2zSbYODh2tMUOasDv9jqdjJ8ZdfnBI2YEah9ottDsvBmhM4OKAgmr vtK2BjBXbugg9sQ0RruH/XfsvY9o8pAYP/rGP4AB0NuPXC+2G1dbvYD11DlboRH/wMuMPBK1Y h7sHFQfGFlYgjnxjKrabdm4e0YgExN04To36KYbZn4pzJMX80Ua9TnobEFfYhwkg1SaoQRW+M 7Bu33p8VOEipXKMKK4xcVh6pA/Z26OtgxApSo52jhfBY15twVNBFSfdzFyqM9P/AO7zUumPWq slQG4b9/NRgbL/qNAj1MVdrQ+fnDqNXzapraNeuxfqvjZP5LOQFGZngBpK3LntW9GtiLHwSnm YLFftmOeq9ElMEeOVVf7nW95/D56EtbEoNifylIJXlWEHrpoBUxYyqiri9fSMEy1VHCRx+SUt SFK8RyAe9C6U8vbXahac0LWF5mYLuZ6M39ZQhdw/YcgFABsxVIGW8rr3no+Dued4M601wJPp 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:268294 Archived-At: Drew Adams writes: > IOW, let's not hope for perfect, and give up because > things are already imperfect (that ship has sailed). > Instead, why not declare that it's better to not add > non-CL stuff to cl-*.el files, and work to keep it > out. Not adding more, and declaring that policy, is > at least better than adding more with no such policy. > > Just one opinion. We could improve things a bit here. My opinion is different. cl-lib enhancing Emacs Lisp well is more important than emulating Common Lisp 100 percent perfectly - which is impossible anyway (no multiple return values, etc.). And we don't have the manpower to separate cl-lib into two libraries - one with the goal to be maximally Common Lisp compliant, the other being a maximally good enhancement for Elisp. So unless someone is willing to invest this not small amount of work, now and in the future (and I want to ask: would this be a good investment of time, given the huge amount of open real bugs)... ... we have to live with the situation that we have only 1 library, and only one definition for every CL thing. And the compromise is that we don't break CL semantics wherever possible, and try to add only stuff that is more or less diagonal to the existing semantics. And this is the case apart from some corner cases that are negligible, compared to the language features we don't provide at all. I don't understand what your actual problems with this situation are. The thing developed into a different direction than you expected, and, IMO, became better, more useful for Emacs. You like CL, ok, you are nonetheless not disallowed to run Common Lisp on your computer or even in Emacs. So, what is goal, why is it better than what we have now, and how do you want to reach that goal? Michael.