From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#69108: false-positive warning "variable =?UTF-8?Q?=E2=80=98=5F=E2=80=99?= not left unused" in if-let* and if-let Date: Sun, 18 Feb 2024 08:53:37 +0200 Message-ID: <86o7ces1ou.fsf@gnu.org> References: <87il2ryi30.fsf@web.de> <87mss09bnc.fsf@web.de> <86eddbv7no.fsf@gnu.org> <874je6agww.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8396"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Hi-Angel@yandex.ru, 69108@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 18 07:55:05 2024 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 1rbb4q-0001zD-TM for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Feb 2024 07:55:04 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rbb4V-0003Bh-Rz; Sun, 18 Feb 2024 01:54:43 -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 1rbb4T-0003BR-V5 for bug-gnu-emacs@gnu.org; Sun, 18 Feb 2024 01:54:42 -0500 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 1rbb4T-0006Sr-Mw for bug-gnu-emacs@gnu.org; Sun, 18 Feb 2024 01:54:41 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rbb4n-0002EL-P9 for bug-gnu-emacs@gnu.org; Sun, 18 Feb 2024 01:55:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Feb 2024 06:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69108 X-GNU-PR-Package: emacs Original-Received: via spool by 69108-submit@debbugs.gnu.org id=B69108.17082392598514 (code B ref 69108); Sun, 18 Feb 2024 06:55:01 +0000 Original-Received: (at 69108) by debbugs.gnu.org; 18 Feb 2024 06:54:19 +0000 Original-Received: from localhost ([127.0.0.1]:34107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbb46-0002DG-Vk for submit@debbugs.gnu.org; Sun, 18 Feb 2024 01:54:19 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rbb44-0002D2-7P for 69108@debbugs.gnu.org; Sun, 18 Feb 2024 01:54:17 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rbb3d-0006PV-3i; Sun, 18 Feb 2024 01:53:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=e8jBDo4t+DWRfkFgJBC6Z0x+6RL3zCHgj/OFQLV4FZc=; b=dont3oOX1CuLkN6bZgPK Z2iTJ8agETpKVnxqKpmNiAJNmgXPIWUdD/MtzeNzVr694TjOPmdNh2N/97fcoDdZa+GZGBV4G32q4 tx4in3+CIz6z84+yxjyqYw2OlsJyFY43ec60fU7Ky6nLKiE0AYtuMQBiYNlbafEHXVsQ6F3xMoAOJ tnklO038eizc/hc6/QHh9GNYU4gsZ1qsI8MPpgJNy7iY1ZVz9/JVM1mhQ5yMyrPIQddILdTnkaOO2 2F/96PLXz4KwWQbB9yfs2Odk+VHTS3JPlvByvFlGv/FP2zaGpWF5QfeEqjR4qlX0umKdaWOHyD7L7 YTOEjnCMmRXsKQ==; In-Reply-To: <874je6agww.fsf@web.de> (message from Michael Heerdegen on Sat, 17 Feb 2024 23:02:07 +0100) 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:280158 Archived-At: > From: Michael Heerdegen > Cc: 69108@debbugs.gnu.org, Hi-Angel@yandex.ru > Date: Sat, 17 Feb 2024 23:02:07 +0100 > > Eli Zaretskii writes: > > > Thanks, but can we please leave this as 'cond', instead of converting > > it to a 'pcase'? It doesn't seem to be justified here, and even less > > so since you need to rewrite all the existing conditions. > > Oh no. > > If I don't rewrite this with `pcase', we would either artificially split > this case: > > ((or `(,test) `(_ ,test)) > (list (make-symbol "s") test)) > > into two separate `cond' branches, or we had to merge them into a one branch > like this: > > ((or (null (cdr binding)) > (eq '_ (car binding))) > (list (make-symbol "s") > (if (null (cdr binding)) > (car binding) > (cadr binding)))) > > repeating a test. Is this what you prefer? Yes, I think so. And you could perhaps avoid repetition of (cdr binding) by saving the result of (null (cdr binding)) in a local variable. Or did I misunderstand the issues? > Please to everyone: let's avoid a new discussion about `pcase'. Please, > not again. It isn't a discussion. I'm asking you (and everyone else) to avoid using pcase where a simple cond will do, certainly when changing code that already uses cond for most of the conditions. That will both decrease the code churn, and thus minimize the probability of inadvertent mistakes, and make the code easier to read for some. > > > [My doc tweaks] > > This hunk seems to be unrelated? > > Yes, I can make it a separate commit it drop it entirely if you prefer. If it's unrelated, then yes, I'd prefer to separate it. > > And it is not necessarily for the better, IMO, at least not all of it > > (replaces active tense with passive, refills text that doesn't need > > refilling, and other minor issues, > > I can try to improve that of course. > > > like the confusing use of construct state in "last ELSE form"). > > Dunno what a "construct state" is. https://en.wikipedia.org/wiki/Construct_state It has to do with juxtaposition of several nouns to express genitive. In this case I meant the replacement of "last form in ELSE" with "the last ELSE form", which is more confusing, because it isn't clear whether "last" refers to "ELSE" or to "form". > The doc missed to tell what `if-let' returns when optional ELSE > forms are omitted (which is allowed, and then there is no last ELSE > form return value), so I tried to add that. Did I mess up the > grammar? The grammar might be okay, but "last form in ELSE" is still better, and your rewording lacks crucial punctuation which could have helped interpreting the text correctly. For example, there should be a comma before "or nil if there are none".