all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: Hi-Angel@yandex.ru, 69108@debbugs.gnu.org
Subject: bug#69108: false-positive warning "variable ‘_’ not left unused" in if-let* and if-let
Date: Sun, 18 Feb 2024 08:53:37 +0200	[thread overview]
Message-ID: <86o7ces1ou.fsf@gnu.org> (raw)
In-Reply-To: <874je6agww.fsf@web.de> (message from Michael Heerdegen on Sat, 17 Feb 2024 23:02:07 +0100)

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 69108@debbugs.gnu.org,  Hi-Angel@yandex.ru
> Date: Sat, 17 Feb 2024 23:02:07 +0100
> 
> Eli Zaretskii <eliz@gnu.org> 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".





  reply	other threads:[~2024-02-18  6:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-13 21:21 bug#69108: false-positive warning "variable ‘_’ not left unused" in if-let* and if-let Konstantin Kharlamov
2024-02-14  1:01 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17  0:28   ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17  8:04     ` Eli Zaretskii
2024-02-17  9:20       ` Konstantin Kharlamov
2024-02-17 11:45         ` Ihor Radchenko
2024-02-17 10:09           ` Konstantin Kharlamov
2024-02-19 12:37             ` Ihor Radchenko
2024-02-19 13:44               ` Konstantin Kharlamov
2024-02-17 21:46         ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 22:02       ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18  6:53         ` Eli Zaretskii [this message]
2024-02-25  1:54           ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-25  7:42             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86o7ces1ou.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=69108@debbugs.gnu.org \
    --cc=Hi-Angel@yandex.ru \
    --cc=michael_heerdegen@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.