GNU bug report logs - #30039
26.0.90; [26.1] Making my code warning free is impossible with when-let

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30039 in the body.
You can then email your comments to 30039 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Damien Cassou <damien <at> cassou.me>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Tue, 09 Jan 2018 08:27:02 +0100

Hi,

I try to make all my packages warning free by setting
byte-compile-error-on-warn and running the byte compiler during
continuous integration. I do that for both Emacs 25 and Emacs 26. This
has become impossible with Emacs 26 because when-let is deprecated but
it’s replacement does not exist in Emacs 25.

I can think of two solutions to make my life easier (and potentially
other package maintainers who care about code quality):

- introduce when-let* (and if-let*) in Emacs 25; or

- un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
  later.

Best

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Message #8 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Petton <nicolas <at> petton.fr>
To: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Tue, 09 Jan 2018 09:16:10 +0100

[Message part 1 (text/plain, inline)]

Damien Cassou <damien <at> cassou.me> writes:

> Hi,

Hi Damien,

> I can think of two solutions to make my life easier (and potentially
> other package maintainers who care about code quality):
>
> - introduce when-let* (and if-let*) in Emacs 25; or

That's probably not an option.

> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
>   later.

I'm facing the same issue, un-deprecating when-let would also make my CI
happier.

Cheers,
Nico

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Damien Cassou <damien <at> cassou.me>
Cc: 30039 <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Tue, 09 Jan 2018 09:05:43 -0500

Damien Cassou <damien <at> cassou.me> writes:

> I try to make all my packages warning free by setting
> byte-compile-error-on-warn and running the byte compiler during
> continuous integration. I do that for both Emacs 25 and Emacs 26. This
> has become impossible with Emacs 26 because when-let is deprecated but
> it’s replacement does not exist in Emacs 25.

Couldn't you do

(eval-when-compile
  (unless (fboundp 'when-let*)
    (defalias 'when-let* 'when-let)))

Message #14 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Damien Cassou <damien <at> cassou.me>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 30039 <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Tue, 09 Jan 2018 15:23:37 +0100

Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
> Couldn't you do
>
> (eval-when-compile
>   (unless (fboundp 'when-let*)
>     (defalias 'when-let* 'when-let)))

sure, that's a possible workaround. I was more talking about a solution
for everyone as I guess I'm not the only one to face the problem.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Message #17 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Damien Cassou <damien <at> cassou.me>
Cc: 30039 <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Tue, 09 Jan 2018 09:43:04 -0500

Damien Cassou <damien <at> cassou.me> writes:

> I can think of two solutions to make my life easier (and potentially
> other package maintainers who care about code quality):
>
> - introduce when-let* (and if-let*) in Emacs 25; or

Since we don't have a time machine, this seems impractical (or if you
mean release 25.4 just for this, kind of overkill).

> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
>   later.

When is "later"?  Wouldn't the problem remain indefinitely?  It kind of
sounds like this is suggestion means Emacs could no longer deprecate
anything.

Message #20 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Damien Cassou <damien <at> cassou.me>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 30039 <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Wed, 10 Jan 2018 13:13:44 +0100

Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
> Since we don't have a time machine, this seems impractical (or if you
> mean release 25.4 just for this, kind of overkill).


I would also like a time machine but I was more referring to a new
release of Emacs 25.


>> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
>>   later.
>
> When is "later"?  Wouldn't the problem remain indefinitely?


That’s a question we need to answer. I think supporting 2 releases would
already be good (i.e., 26.1 does not deprecate but 26.2 does).


> It kind of sounds like this is suggestion means Emacs could no longer
> deprecate anything.


I’m all in favor of deprecation. This is important to move forward.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Message #23 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Damien Cassou <damien <at> cassou.me>
Cc: 30039 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Wed, 10 Jan 2018 17:45:49 +0200

> From: Damien Cassou <damien <at> cassou.me>
> Date: Wed, 10 Jan 2018 13:13:44 +0100
> Cc: 30039 <at> debbugs.gnu.org
> 
> Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
> > Since we don't have a time machine, this seems impractical (or if you
> > mean release 25.4 just for this, kind of overkill).
> 
> 
> I would also like a time machine but I was more referring to a new
> release of Emacs 25.

You mean, release Emacs 25.4 with this single change?  That's unlikely
to happen.  And even if it did, I don't understand what problem would
it solve: people who have previous versions will still need to
upgrade, and you can tell them to upgrade to Emacs 26.1 exactly as you
can tell them to upgrade to 25.4.  What am I missing?

> >> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
> >>   later.
> >
> > When is "later"?  Wouldn't the problem remain indefinitely?
> 
> That’s a question we need to answer. I think supporting 2 releases would
> already be good (i.e., 26.1 does not deprecate but 26.2 does).

That's not how we deprecate stuff.  We never wait with deprecation,
only with the actual removal.

Message #26 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Petton <nicolas <at> petton.fr>
To: Eli Zaretskii <eliz <at> gnu.org>, Damien Cassou <damien <at> cassou.me>
Cc: 30039 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Wed, 10 Jan 2018 17:24:43 +0100

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> That’s a question we need to answer. I think supporting 2 releases would
>> already be good (i.e., 26.1 does not deprecate but 26.2 does).
>
> That's not how we deprecate stuff.  We never wait with deprecation,
> only with the actual removal.

But in this case it leads to an issue with linting: when-let cannot be
used in packages if we want to support both Emacs 25 and 26, since
when-let has been deprecated and when-let* didn't exist in Emacs 25.

Of course the linter could be tweaked in the CI to keep builds green,
but that feels like a hack.

Nico

[signature.asc (application/pgp-signature, inline)]

Message #29 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Nicolas Petton <nicolas <at> petton.fr>
Cc: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, npostavs <at> users.sourceforge.net
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Wed, 10 Jan 2018 12:24:04 -0500

Nicolas Petton wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> That's a question we need to answer. I think supporting 2 releases would
>>> already be good (i.e., 26.1 does not deprecate but 26.2 does).
>>
>> That's not how we deprecate stuff.  We never wait with deprecation,
>> only with the actual removal.
>
> But in this case it leads to an issue with linting: when-let cannot be
> used in packages if we want to support both Emacs 25 and 26, since
> when-let has been deprecated and when-let* didn't exist in Emacs 25.

What's special about this case?
If you:
1) require a warning-free compilation in two releases of Emacs with the
same codebase
2) decline to use standard techniques such as https://debbugs.gnu.org/30039#11

then isn't the conclusion that *nothing* can be marked obsolete unless
the replacement existed in the previous release? Are you asking for this
to become Emacs policy?

Surely this would slow down the adoption of new techniques (because
people wouldn't start seeing the obsolescence warnings till another
release goes by).

I don't like compilation warnings either, but this position seems odd to
me.

Message #32 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Petton <nicolas <at> petton.fr>
Cc: damien <at> cassou.me, 30039 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Wed, 10 Jan 2018 20:46:08 +0200

> From: Nicolas Petton <nicolas <at> petton.fr>
> Cc: 30039 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
> Date: Wed, 10 Jan 2018 17:24:43 +0100
> 
> >> That’s a question we need to answer. I think supporting 2 releases would
> >> already be good (i.e., 26.1 does not deprecate but 26.2 does).
> >
> > That's not how we deprecate stuff.  We never wait with deprecation,
> > only with the actual removal.
> 
> But in this case it leads to an issue with linting: when-let cannot be
> used in packages if we want to support both Emacs 25 and 26, since
> when-let has been deprecated and when-let* didn't exist in Emacs 25.

It's unfortunate that we got into this situation, but we cannot change
the past, can we?  And releasing another Emacs 25.x, even if we decide
to do that, will change nothing, because users of Emacs 25.3 and older
will still have the same problem.

And frankly, a few byte-compilation warnings are not such a
catastrophe, we have many dozens of them when we build Emacs.

Message #35 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Nicolas Petton <nicolas <at> petton.fr>
Cc: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90; [26.1] Making my code warning free is
 impossible with when-let
Date: Wed, 10 Jan 2018 14:11:47 -0500

[Message part 1 (text/plain, inline)]

On Tue, Jan 9, 2018 at 3:16 AM, Nicolas Petton <nicolas <at> petton.fr> wrote:

>> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
>>   later.
>
> I'm facing the same issue, un-deprecating when-let would also make my CI
> happier.

How about adding a variable which suppresses deprecation warnings from
a specified version and up. Attached is a work-in-progress patch which
would allow you to set byte-compile-not-obsolete-since to "25.1" in
your CI script (or file-locally) and thus ignore deprecation warnings
from 26.1 or newer.

Alternatively, or additionally, we could let
`byte-compile-not-obsolete-funcs' apply to macros as well (currently
macroexp-macroexpand doesn't consult it).

[v1-0001-WIP-Allow-suppressing-obsoletion-warnings-per-ver.patch (application/octet-stream, attachment)]

Message #38 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Petton <nicolas <at> petton.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: damien <at> cassou.me, 30039 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Wed, 10 Jan 2018 22:48:33 +0100

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> And releasing another Emacs 25.x, even if we decide to do that, will
> change nothing, because users of Emacs 25.3 and older will still have
> the same problem.

That's true, I didn't propose to do that.

> And frankly, a few byte-compilation warnings are not such a
> catastrophe, we have many dozens of them when we build Emacs.

It's definitely not a big deal, but I mentioned the issue with CI &
linting as I think issues like this one could be in the way of their
adoption by package authors.

Nico

[signature.asc (application/pgp-signature, inline)]

Message #41 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Petton <nicolas <at> petton.fr>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Wed, 10 Jan 2018 22:50:40 +0100

[Message part 1 (text/plain, inline)]

Noam Postavsky <npostavs <at> users.sourceforge.net> writes:

> How about adding a variable which suppresses deprecation warnings from
> a specified version and up. Attached is a work-in-progress patch which
> would allow you to set byte-compile-not-obsolete-since to "25.1" in
> your CI script (or file-locally) and thus ignore deprecation warnings
> from 26.1 or newer.

I think that could be a nice workaround, thanks.  What do others think?

Nico

[signature.asc (application/pgp-signature, inline)]

Message #44 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Nicolas Petton <nicolas <at> petton.fr>
Cc: damien <at> cassou.me, 30039 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Wed, 10 Jan 2018 14:05:57 -0800

Nicolas Petton <nicolas <at> petton.fr> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> And releasing another Emacs 25.x, even if we decide to do that, will
>> change nothing, because users of Emacs 25.3 and older will still have
>> the same problem.
>
> That's true, I didn't propose to do that.
>
>> And frankly, a few byte-compilation warnings are not such a
>> catastrophe, we have many dozens of them when we build Emacs.
>
> It's definitely not a big deal, but I mentioned the issue with CI &
> linting as I think issues like this one could be in the way of their
> adoption by package authors.

I removed uses of when-let from my packages altogether, just because I
was being OCD about the compiler warnings. I've encountered no other
functions where the introduction-deprecation-removal cycle has been so
tight that I have to choose between compiler warnings on the one hand,
or multiple users running an Emacs without the function, on the other.

I agree it's not a big deal, for all the reasons already brought up, but
it was a bit of a frustration.

My 0.5¢,
Eric

Message #47 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org,
 Nicolas Petton <nicolas <at> petton.fr>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#30039: 26.0.90; [26.1] Making my code warning free is
 impossible with when-let
Date: Wed, 10 Jan 2018 17:23:16 -0500

On Wed, Jan 10, 2018 at 5:05 PM, Eric Abrahamsen
<eric <at> ericabrahamsen.net> wrote:
> I've encountered no other
> functions where the introduction-deprecation-removal cycle has been so
> tight that I have to choose between compiler warnings on the one hand,
> or multiple users running an Emacs without the function, on the other.

Isn't it standard Emacs practice to mark a function deprecated in the
same commit which introduces the replacement? Examples:

[1: 6f1dea5]: 2017-10-18 18:43:44 -0700
  Spelling fixes
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6f1dea5c74057707bf367f863a8be5750bbb6094

[2: 91932ff]: 2017-02-23 22:39:53 -0500
  Use cl-print for Edebug and EIEIO
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=91932fff1ded8ed3b4d39dd06891f26960153b9e

[3: 3db521c]: 2016-06-07 21:34:51 -0400
  Reduce allout.el's pollution of the namespace.
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3db521ccaf3a5b6892bf23ea1305c7cfe9aa1cce

Message #50 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Petton <nicolas <at> petton.fr>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>,
 Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Wed, 10 Jan 2018 23:40:08 +0100

[Message part 1 (text/plain, inline)]

Noam Postavsky <npostavs <at> users.sourceforge.net> writes:

> Isn't it standard Emacs practice to mark a function deprecated in the
> same commit which introduces the replacement? Examples:

Yes, but I think it's quite seldom to have a function introduced, then
deprecated in such a short period.  And from what I've seen, if-let and
when-let popular are quite among package authors.

Nico

[signature.asc (application/pgp-signature, inline)]

Message #53 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Nicolas Petton <nicolas <at> petton.fr>
Cc: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org,
 Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Wed, 10 Jan 2018 14:57:16 -0800

Nicolas Petton <nicolas <at> petton.fr> writes:

> Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
>
>> Isn't it standard Emacs practice to mark a function deprecated in the
>> same commit which introduces the replacement? Examples:
>
> Yes, but I think it's quite seldom to have a function introduced, then
> deprecated in such a short period.  And from what I've seen, if-let and
> when-let popular are quite among package authors.

Right, and the issue wasn't the introduction of when-let*, it was the
very short life-cycle of when-let.

Message #56 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org,
 Nicolas Petton <nicolas <at> petton.fr>
Subject: Re: bug#30039: 26.0.90; [26.1] Making my code warning free is
 impossible with when-let
Date: Wed, 10 Jan 2018 18:06:20 -0500

On Wed, Jan 10, 2018 at 5:57 PM, Eric Abrahamsen
<eric <at> ericabrahamsen.net> wrote:

> Right, and the issue wasn't the introduction of when-let*, it was the
> very short life-cycle of when-let.

I don't understand how that leads to this:

    I have to choose between compiler warnings on the one hand,
    or multiple users running an Emacs without the function, on the other.

Supposing when-let* was only introduced as a replacement to when-let
in Emacs 30, you would still have to choose between users of Emacs 29
reporting errors, or get deprecation warnings when compiling in Emacs
30. The (hypothetical) longer non-deprecated existence of when-let
over versions 26,27,28,29 wouldn't help (unless you plan to stop
developing your package before Emacs 30, I guess).

Message #59 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org,
 Nicolas Petton <nicolas <at> petton.fr>
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Wed, 10 Jan 2018 16:03:45 -0800

On 01/10/18 18:06 PM, Noam Postavsky wrote:
> On Wed, Jan 10, 2018 at 5:57 PM, Eric Abrahamsen
> <eric <at> ericabrahamsen.net> wrote:
>
>> Right, and the issue wasn't the introduction of when-let*, it was the
>> very short life-cycle of when-let.
>
> I don't understand how that leads to this:
>
>     I have to choose between compiler warnings on the one hand,
>     or multiple users running an Emacs without the function, on the other.
>
> Supposing when-let* was only introduced as a replacement to when-let
> in Emacs 30, you would still have to choose between users of Emacs 29
> reporting errors, or get deprecation warnings when compiling in Emacs
> 30. The (hypothetical) longer non-deprecated existence of when-let
> over versions 26,27,28,29 wouldn't help (unless you plan to stop
> developing your package before Emacs 30, I guess).

Ah, you're right. I guess it's just a matter of what Nicolas
mentioned -- these are awfully handy macros, and we're adopting them
early.

Message #62 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Petton <nicolas <at> petton.fr>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org,
 Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Thu, 11 Jan 2018 10:02:30 +0100

[Message part 1 (text/plain, inline)]

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

>> Yes, but I think it's quite seldom to have a function introduced, then
>> deprecated in such a short period.  And from what I've seen, if-let and
>> when-let popular are quite among package authors.
>
> Right, and the issue wasn't the introduction of when-let*, it was the
> very short life-cycle of when-let.

I think this issue should be closed.  While it is a bit of an annoyance,
I don't think there's much to do about it.

Nico

[signature.asc (application/pgp-signature, inline)]

Message #65 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Damien Cassou <damien <at> cassou.me>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>,
 Nicolas Petton <nicolas <at> petton.fr>
Cc: 30039 <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Thu, 11 Jan 2018 10:19:44 +0100

Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
> How about adding a variable which suppresses deprecation warnings from
> a specified version and up. Attached is a work-in-progress patch which
> would allow you to set byte-compile-not-obsolete-since to "25.1" in
> your CI script (or file-locally) and thus ignore deprecation warnings
> from 26.1 or newer.

that’s a nice workaround. Is it too late for an inclusion in 26.1? I
guess what I’m really after is a configurable lint tool…

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Message #68 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Damien Cassou <damien <at> cassou.me>
Cc: 30039 <at> debbugs.gnu.org, Nicolas Petton <nicolas <at> petton.fr>
Subject: Re: bug#30039: 26.0.90; [26.1] Making my code warning free is
 impossible with when-let
Date: Fri, 19 Jan 2018 15:00:30 -0500

[Message part 1 (text/plain, inline)]

On Thu, Jan 11, 2018 at 4:19 AM, Damien Cassou <damien <at> cassou.me> wrote:
> Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
>> How about adding a variable which suppresses deprecation warnings from
>> a specified version and up. Attached is a work-in-progress patch which
>> would allow you to set byte-compile-not-obsolete-since to "25.1" in
>> your CI script (or file-locally) and thus ignore deprecation warnings
>> from 26.1 or newer.
>
> that’s a nice workaround. Is it too late for an inclusion in 26.1? I
> guess what I’m really after is a configurable lint tool…

Here's a finished version of the patch. Eli, is it okay for emacs-26?

[v2-0001-Allow-suppressing-obsoletion-warnings-per-version.patch (application/octet-stream, attachment)]

Message #71 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: damien <at> cassou.me, 30039 <at> debbugs.gnu.org, nicolas <at> petton.fr
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Fri, 19 Jan 2018 22:26:26 +0200

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Fri, 19 Jan 2018 15:00:30 -0500
> Cc: 30039 <at> debbugs.gnu.org, Nicolas Petton <nicolas <at> petton.fr>
> 
> Here's a finished version of the patch. Eli, is it okay for emacs-26?

Why is this new feature is urgent or important enough to have it in
Emacs 26?

Message #74 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org,
 Nicolas Petton <nicolas <at> petton.fr>
Subject: Re: bug#30039: 26.0.90; [26.1] Making my code warning free is
 impossible with when-let
Date: Fri, 19 Jan 2018 15:40:22 -0500

On Fri, Jan 19, 2018 at 3:26 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Fri, 19 Jan 2018 15:00:30 -0500
>> Cc: 30039 <at> debbugs.gnu.org, Nicolas Petton <nicolas <at> petton.fr>
>>
>> Here's a finished version of the patch. Eli, is it okay for emacs-26?
>
> Why is this new feature is urgent or important enough to have it in
> Emacs 26?

It's urgent, because it has to be in 26.1 in order to solve the
problem in the OP. More generally, if we introduce the feature in 26.1
in can be useful for suppressing warnings from 26.1 and up, whereas if
we delay it until 27, then it won't be helpful for things marked
obsolete in 26.1. So the timing of when we add it directly affects the
usefulness.

On the other hand, it's maybe not that important, as the problem is
only a warning, and there are other ways of suppressing it (e.g., what
I suggested in #11).

Message #77 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: damien <at> cassou.me, 30039 <at> debbugs.gnu.org, nicolas <at> petton.fr
Subject: Re: bug#30039: 26.0.90; [26.1] Making my code warning free is
 impossible with when-let
Date: Sat, 20 Jan 2018 09:42:29 +0200

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Fri, 19 Jan 2018 15:40:22 -0500
> Cc: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org, 
> 	Nicolas Petton <nicolas <at> petton.fr>
> 
> On Fri, Jan 19, 2018 at 3:26 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> >> Date: Fri, 19 Jan 2018 15:00:30 -0500
> >> Cc: 30039 <at> debbugs.gnu.org, Nicolas Petton <nicolas <at> petton.fr>
> >>
> >> Here's a finished version of the patch. Eli, is it okay for emacs-26?
> >
> > Why is this new feature is urgent or important enough to have it in
> > Emacs 26?
> 
> It's urgent, because it has to be in 26.1 in order to solve the
> problem in the OP.

But the problem in the OP is just a minor nuisance.

> More generally, if we introduce the feature in 26.1
> in can be useful for suppressing warnings from 26.1 and up, whereas if
> we delay it until 27, then it won't be helpful for things marked
> obsolete in 26.1. So the timing of when we add it directly affects the
> usefulness.
> 
> On the other hand, it's maybe not that important, as the problem is
> only a warning, and there are other ways of suppressing it (e.g., what
> I suggested in #11).

Exactly.  And since the 26.0.91 pretest is already tarred, and just
awaits to be uploaded, I'd prefer from now on to install on the
release branch only stuff that is really necessary (and documentation
patches).

Message #80 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Damien Cassou <damien <at> cassou.me>
Cc: 30039 <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Wed, 21 Feb 2018 23:28:51 +0100

Hi Damien,

> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it
>   later.

In the meantime, Stefan Monnier has brought up the issue again in
emacs-dev.  In that discussion we have come to the conclusion that we
want to make when-let and if-let aliases for when-let* and if-let* in
Emacs 26.  Should happen in the next days.


Michael.

Message #83 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Damien Cassou <damien <at> cassou.me>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 30039 <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Thu, 22 Feb 2018 08:42:33 +0100

Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> In the meantime, Stefan Monnier has brought up the issue again in
> emacs-dev.  In that discussion we have come to the conclusion that we
> want to make when-let and if-let aliases for when-let* and if-let* in
> Emacs 26.  Should happen in the next days.


I'm happy. Thank you!

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Message #88 received at 30039-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Damien Cassou <damien <at> cassou.me>
Cc: 30039-done <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Tue, 06 Mar 2018 16:12:31 +0100

Damien Cassou <damien <at> cassou.me> writes:

> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> > In the meantime, Stefan Monnier has brought up the issue again in
> > emacs-dev.  In that discussion we have come to the conclusion that
> > we want to make when-let and if-let aliases for when-let* and
> > if-let* in Emacs 26.  Should happen in the next days.
>
> I'm happy. Thank you!

I've now installed an according change into emacs-26 (I hope it wasn't
too late for this change to be accepted in the release branch).

Thanks for bringing this up.  Closing.


Regards,

Michael.

Message #95 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Nicolas Petton <nicolas <at> petton.fr>
Cc: Eric Abrahamsen <eric <at> ericabrahamsen.net>, Damien Cassou <damien <at> cassou.me>,
 Noam Postavsky <npostavs <at> users.sourceforge.net>, 30039 <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Sat, 14 Apr 2018 22:17:45 +0200

The warnings for when-let  were removed from Emacs 26, I think?  So I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #98 received at 30039 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eric Abrahamsen <eric <at> ericabrahamsen.net>, Damien Cassou <damien <at> cassou.me>,
 Nicolas Petton <nicolas <at> petton.fr>,
 Noam Postavsky <npostavs <at> users.sourceforge.net>, 30039 <at> debbugs.gnu.org
Subject: Re: bug#30039: 26.0.90;
 [26.1] Making my code warning free is impossible with when-let
Date: Sun, 15 Apr 2018 13:53:48 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> The warnings for when-let were removed from Emacs 26, I think?  So I'm
> closing this bug report.

Yes, dunno why I forgot to close it.  Thanks.

Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.