From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Vasilij Schneidermann Newsgroups: gmane.emacs.devel Subject: Dealing with obsoletion warnings in non-core code Date: Mon, 28 Sep 2020 16:35:40 +0200 Message-ID: <20200928143540.GB1002@odonien.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35141"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 28 16:38:51 2020 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 1kMuIl-00093s-Cx for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Sep 2020 16:38:51 +0200 Original-Received: from localhost ([::1]:36124 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kMuIk-00011d-Cq for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Sep 2020 10:38:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56162) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kMuFx-0006Rp-7f for emacs-devel@gnu.org; Mon, 28 Sep 2020 10:35:57 -0400 Original-Received: from mout-p-202.mailbox.org ([80.241.56.172]:64758) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1kMuFq-0005Id-3q for emacs-devel@gnu.org; Mon, 28 Sep 2020 10:35:56 -0400 Original-Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4C0Q6m029RzQlJx for ; Mon, 28 Sep 2020 16:35:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Original-Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter06.heinlein-hosting.de (spamfilter06.heinlein-hosting.de [80.241.56.125]) (amavisd-new, port 10030) with ESMTP id Ea8AI8YGFtBs for ; Mon, 28 Sep 2020 16:35:41 +0200 (CEST) Mail-Followup-To: emacs-devel@gnu.org Content-Disposition: inline X-Rspamd-Score: -6.90 / 15.00 / 15.00 X-Rspamd-Queue-Id: 0A16D274 X-Rspamd-UID: eb35c7 Received-SPF: pass client-ip=80.241.56.172; envelope-from=mail@vasilij.de; helo=mout-p-202.mailbox.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/28 10:35:44 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:256598 Archived-At: --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Here's something that keeps irking me when maintaining community packages written back when Emacs 24.3 was a reasonable version to support: With every new Emacs release I receive more and more byte-compiler warnings that are tricky to silence. One pattern that keeps showing up is that of functions/variables the byte-compiler doesn't know about (for example because these are only available in a future Emacs release), for those it's possible to use a conditional testing for the function/variable existence: (if (fboundp 'new-and-exciting-function) (new-and-exciting-function) (boring-function)) The same trick however cannot be used for functions/variables declared obsoleted, the only construct I've found to work in this case is the following: (with-suppressed-warnings ((obsolete old-but-useful-function)) (if (fboundp 'recommended-function) (recommended-function) (old-but-useful-function))) Ideally I'd like to be able to write the following instead to avoid the needless repetition: (if (fboundp 'recommended-function) (recommended-function) (old-but-useful-function)) Is there something I'm overlooking here? I've looked at core code and it seems to mostly ignore this kind of compatibility issue and instead drops all obsolete usage. This is not always an option as community package author. Many authors and users just ignore warnings, especially if they can't do anything about them. This leads to fatigue and might let them overlook actually important warnings. --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE0dAcySl3bqM8O17WFmfJg6zCifoFAl9x9LMACgkQFmfJg6zC ifpOawgAteJsYXcxDsJYCqAwsl4uIlM5/fDRtyAwNzj3dvF0yQsPaj3CBedTBwyk DaHLHwfu54nJyRPuA7fYLwblU23zkWCfzBUaIPAH2ZqpwOUJYiIZ4t6wxdPegLSf ewc2RGH/Vq+UFrERfMhQ99xe6oRKp7RKC+HusPg8Fza3HBaVwAv87gusOuF8TbjS VBlQXBXarHXvIYmR400k2jPza/N5CChkWSe9E6wuSN+iFLQ4xqKKrqUUU3HWZF0R qrFnQb6c/QBDVPI5aqrxSur+ULffGgydPyhxCDCyejX2aAFI1iSNurc2AjH+ZhlG W9gKrJhpARuF7sAZgmQVApPfHNX6RQ== =t8uI -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig--