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: Obtaining a database of new functionality per Emacs version Date: Mon, 7 Dec 2020 13:23:29 +0100 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="965cJQ+5z+pNJgNZ" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25085"; 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 Dec 07 14:31:48 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 1kmGcF-0006OA-EM for ged-emacs-devel@m.gmane-mx.org; Mon, 07 Dec 2020 14:31:47 +0100 Original-Received: from localhost ([::1]:49120 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmGcE-0006bH-EK for ged-emacs-devel@m.gmane-mx.org; Mon, 07 Dec 2020 08:31:46 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmFYZ-0007gJ-0Q for emacs-devel@gnu.org; Mon, 07 Dec 2020 07:24:01 -0500 Original-Received: from mout-p-202.mailbox.org ([80.241.56.172]:21602) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1kmFYS-0003SH-BT for emacs-devel@gnu.org; Mon, 07 Dec 2020 07:23:54 -0500 Original-Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (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 4CqMsx4PrLzQkjT for ; Mon, 7 Dec 2020 13:23:33 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Original-Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id yGYHqSD2Fkn7 for ; Mon, 7 Dec 2020 13:23:30 +0100 (CET) Mail-Followup-To: emacs-devel@gnu.org Content-Disposition: inline X-Rspamd-Score: -6.70 / 15.00 / 15.00 X-Rspamd-Queue-Id: A57B81855 X-Rspamd-UID: c18a48 Received-SPF: pass client-ip=80.241.56.172; envelope-from=mail@vasilij.de; helo=mout-p-202.mailbox.org 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01 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:260475 Archived-At: --965cJQ+5z+pNJgNZ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hello everyone, I'm looking into creating a tool helping me with ensuring that my packages actually support the Emacs versions they claim to by highlighting uses of unsupported functions/variables [1]. For example if I were to commit myself on supporting Debian stable with its Emacs 26.1, that tool would highlight uses of `with-suppressed-warnings`, a macro introduced in Emacs 27.1. The first problem to tackle is that there doesn't seem to be a ready-made database. I've identified the following options for making my own: - Relying on metadata from custom.el: Works on customizables only. - Combing through NEWS files: Not machine-readable, tedious, prone to mistakes (not all new functionality is marked as such, for example there's renames like `with-connection-local-profiles` to `with-connection-local-variables`). - Combing through CHANGELOG: Not machine-readable either, tedious, not cleanly separated by versions, seemingly the wrong data source to consult. - Launching an Emacs process, loading up all functionality, dumping all symbols, diffing against the output of an Emacs process of an older version, filtering out symbols introduced by our own code: This might just work (loading up functionality has side effects), but surely there's a better way, right? Anything obvious I'm overlooking? Should there perhaps be an effort towards documenting versioned public API? Vasilij [1]: I realize that this is far from solving the whole problem as incorrect uses might still slip through, for example APIs taking a different amount of arguments. To detect these, CI is required. However I believe there is still merit to a tool run before CI kicks in... --965cJQ+5z+pNJgNZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE0dAcySl3bqM8O17WFmfJg6zCifoFAl/OHrgACgkQFmfJg6zC ifpVpQf/S+yl7lQLBLT44k0b9bT+1Ko7r7PQjtMgm2krTxYRkizATXnrpD64yoAw 9iK/b2gmTW54znujZl5IHxVS7nnwkBP9NXo5tjcI7q0D257cPCYWJK//zF5rfs6E +y5zULRl461RP76yBkuE3zXqF36O3LM8Q3DXGBQ/bAd8ebDb2LvUc1HeN0y8XYcT QZVz1vRs+fb51HsIMkwn/u4/NV1EUiBRqdLhnWTUgafIKAZDmOHb5ohWHyd7/z2x /w4B040rVgMhaoSl7buhTj47CY8LgAS0QFC1a64lGRVNu0F53rfrjDDkjsl42X4P ZzbJ0J0DaRH/IiyFw/Pejl/VXzJ6Nw== =6Tik -----END PGP SIGNATURE----- --965cJQ+5z+pNJgNZ--