From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: Code for cond* Date: Thu, 25 Jan 2024 15:08:23 +0100 Message-ID: <871qa5eca0.fsf@dataswamp.org> References: <874jf3rkzx.fsf@yahoo.com> <87le8ehqew.fsf@localhost> <87zfwurjv4.fsf@yahoo.com> <87cytqhn35.fsf@localhost> <87r0i6rfjg.fsf@yahoo.com> <874jf2hkxo.fsf@localhost> <87frymre9b.fsf@yahoo.com> <871qa6hjtq.fsf@localhost> <87y1ceeoo3.fsf@dataswamp.org> <87o7d9pysz.fsf@yahoo.com> <87frylps5u.fsf@yahoo.com> <87a5otehzo.fsf@dataswamp.org> <87y1cdo7wd.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20100"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:uqF8XdEbQ+znO0ZSgtdaqA7r3uM= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 25 15:27:21 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rT0hM-0004yy-ID for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Jan 2024 15:27:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rT0gx-0002Pl-Sb; Thu, 25 Jan 2024 09:26:55 -0500 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 1rT0PH-0005z2-Dk for emacs-devel@gnu.org; Thu, 25 Jan 2024 09:08:39 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rT0PD-0001lZ-VO for emacs-devel@gnu.org; Thu, 25 Jan 2024 09:08:38 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rT0P9-0000n8-VP for emacs-devel@gnu.org; Thu, 25 Jan 2024 15:08:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 25 Jan 2024 09:26:54 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315360 Archived-At: Po Lu wrote: >> What you can say is "Hey, we have something interesting >> here, take a look, hopefully it will gain traction if >> people are appealed by it". >> >> But you are not saying that because you yourself are not >> confident cond* really has any such advantages over `pcase' >> to motivate anything close to this kind of >> confrontational approach. > > I can't so much as understand pcase forms, let alone debate > the fine technical details that certain participants in this > thread insist demonstrate the superiority of pcase over > cond*. It can be and is sometimes pretty unclear but it is clear enough that cond* is not superior to `pcase' in any way that even remotely motivates this kind of confrontational attitude. To propose pcase should be replaced by it is bizarre at this point. > But if you read my words carefully, it will be apparent that > all I have asked is that people refrain from contriving > reasons to exclude cond* from Emacs. Richard already made up > his mind [...] To include cond*, or to have a grandiose plan to have it replace pcase? Because those are two different things. If the plan is to kick out pcase I'm sure there is a plan to kick out cl-lib as well, since the last time we heard about this, what we first heard wasn't of pcase, but cl-lib. Only when it become clear almost no one in the Emacs community was in favor of kicking out cl-lib the focus switched to pcase. Hey, include whatever you want and let it play out anyway it happens. But grandiose politics with tailored software and PR campaigns to support it - no thanks. -- underground experts united https://dataswamp.org/~incal