From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Proposal: Forwards-Compatibility Library for Emacs Date: Tue, 21 Sep 2021 15:27:24 +0200 Message-ID: References: <877dfavmzw.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9618"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 21 15:28:22 2021 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 1mSfoq-0002E8-0z for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 15:28:21 +0200 Original-Received: from localhost ([::1]:45560 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSfon-0001ZY-Uy for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 09:28:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56042) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSfo2-0000tJ-UT for emacs-devel@gnu.org; Tue, 21 Sep 2021 09:27:30 -0400 Original-Received: from mail-oln040092075031.outbound.protection.outlook.com ([40.92.75.31]:44975 helo=EUR04-VI1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSfo0-0008U5-Kh for emacs-devel@gnu.org; Tue, 21 Sep 2021 09:27:30 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ewx0ghjfrRatzDDKVEeWS6rygy6IlpQR2P87M8yqxgf0qkEHVvlj2yRE6syrfFOIEBtqcceZM0E743v8AoUtl8ZZ3CI++q621EeABWHrfmozGxUfUWH8ZzONF3lsbhric88ZdLA9sVUITSjFZ76PeCSO99dNB8yEHc8p1E7lrRFen1yd3ZSHBA7UF5FO9jGbXkq66hnBCK0qdxULS7WWKLnK+WDXiKbZare2nfU2GbjfCnbh4P1jl//i51DzdjD2qpnuaUT0jsLCtAIWGQHvUrQ7cJtZ+y8PwXdu1fS2SoYs6+vK5sWIOXfdvIdY6IbqBPtpVHH9/xDi1z22O70mMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zWogDDC2MHm77bLeJDs+vW6BLelC3pf+5om0arcnncw=; b=BZztynnqmm//Hf0JCdUzoQRME1B3wcC93JFdwPYJnZd72qS38je8P8UrMHfWFmmjcjYGJP+05TLfvP32zd6SceG5oElLgP1iS/CdQNOqFYw1tRTarsq3ad/4Z+Vw91A2MWeCjXPFc9BDCJBW/Ftle/5Bdz6GobSQIEU1w+/JyRLZb3nMkMweC0sDRJ3GXl1e7uaOYhQbO1wsPIpIH33Ch9IT1DG3gnDA9Ywiry7O6m5YH366iErFwgUdtJwJLiNYaKVaLCBrJ/LOf4l/15aMVjpEeysRX0t6+q0PjD6jBt4Ksf9v1tXUQ93+Ge9duYr7MYdX0yEjaej4V8uA9ihakQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zWogDDC2MHm77bLeJDs+vW6BLelC3pf+5om0arcnncw=; b=lXvxkNjrcVYYRVzRzpHDb4npzCsQraM6qfL9QNFAgZaOJ2PPo91hqxREu4pHnbJhVPQ2FUTuvlA0UFf+rujhQFpctIRTajQHNWIPsDQtojvfzHatE3Nf2W2lHx2RKp5MKln1qxFgVH2Pf6Nitc0jOvtMGe6hfrZA/SVgc9u2DfF+30w9R6FbITglub95VWqPFdXl+GJZ37UaGDhemvKdtnpYXc8KFhmgTSiL5AXaoedbwF+bWPB7E7CfNComh+3WLs729XA1HVv+jZPsvoj/mcJO2yHuHIjYy4P3efaikh4XRulvrGVeM6IFTSNbnH6+1oVKAqk1TRpJhnZz1MFw7A== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by AM9PR09MB4980.eurprd09.prod.outlook.com (2603:10a6:20b:302::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.13; Tue, 21 Sep 2021 13:27:25 +0000 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::c55c:ece5:bed2:a9dc]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::c55c:ece5:bed2:a9dc%9]) with mapi id 15.20.4544.013; Tue, 21 Sep 2021 13:27:25 +0000 In-Reply-To: <877dfavmzw.fsf@posteo.net> (Philip Kaludercic's message of "Mon, 20 Sep 2021 23:35:47 +0000") X-TMN: [sRisPb9yz6D0krWRZ7PwRtiScJ00Mezo] X-ClientProxiedBy: AS8P250CA0011.EURP250.PROD.OUTLOOK.COM (2603:10a6:20b:330::16) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <874kaerrcz.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from pascal.homepc (81.232.177.30) by AS8P250CA0011.EURP250.PROD.OUTLOOK.COM (2603:10a6:20b:330::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.13 via Frontend Transport; Tue, 21 Sep 2021 13:27:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 19f64827-4930-4e00-4a8f-08d97d038cea X-MS-TrafficTypeDiagnostic: AM9PR09MB4980: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HLt+Zhxn8DhEhZewzia4Gg9qNUl6cEFKtVHH9zY/b4V97VGt1YUZ1AY0BLUIMNpoZWbv1NYiHSMDOuxrsTlS+Bv38wQiMTE8MkSXLR5k+/N8leEWm9Ia1QcKzaxv3h16IqrOsfdd0Is6s5lNhW4hVs+x7/k5UmDWMta0vUxyDTKmI0YB9cOknfzm4f+UMlKFbDm1cr2Os3Gw+/ygvDM7aD+QTvjHjYLPkeYCHuKXA1JJ0MdabW9xSzAXq8wMrXdfE0iNXmw2de2VmUA+2sijS7XmuNwucqyEV+PloMw0HCJ1lrhtK7zSi0weVXCOjxQa6jPhqCT+JvtRamDsnXFjgDYuIGKEvTx43GwE36eLpY4oufSEKb99pkOy6vG1LaAl1e/zCg5XCe0RwuHNe2RqSBPolEhDev/mFe9JZR6tTZJGcp2XWrlNf6M0j25JUfyT X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 95sNZV+Yy1637I1qvoyt+XMd4gaBFZ3HS6MbbHhLQi5DNdebFRVrf+Mqtw1ji7CwtCv53liOcY69fnTQljb2lbS+srzLA5br2XC0nGi+dUoOgzxnF3tphJTNdHkD+30p7ONV5m3GXIqsBlH92aWGFg== X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-72e6e.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 19f64827-4930-4e00-4a8f-08d97d038cea X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2021 13:27:25.6923 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR09MB4980 Received-SPF: pass client-ip=40.92.75.31; envelope-from=arthur.miller@live.com; helo=EUR04-VI1-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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:275228 Archived-At: Philip Kaludercic writes: > The idea is to allow developers who don't want to break backwards > compatibility to use newer functionality that wasn't provided in older > versions of Emacs. This version tries to implement as much as possible > from Emacs 24.2 onwards. > > By its very nature it is an intrusive package, as it defines functions, > macros and advice outside of the "namespace", but I don't see any way > around that if transparent compatibility is to be provided (anything > else would just replicate dash, s, f, ...). Is there a problem if something replicates something else? :) If it is a good thing, we just call it a "design pattern". > As some of the functions are lisp reimplementations of core functions, > there exists the risk of a performance overhead. To minimize this, the > compatibility layer is only applied necessary: Ideally someone using > Emacs 28.1 should have a quasi-empty file, with all the definitions > byte-compiled away. > > Eventually I would like to propose adding something like this to > ELPA. It would only makes sense, as more than a few functions were > copied verbatim or quasi-verbatim from Emacs itself. I had a similar idea once, and I think it definitely belongs to an external package. If you had this as an external library, than people who use older Emacs:es could install compat-libs as a package, and in cases where there is a compatibility function provided, they would just load a compat library after a package is loaded. Say I use dired-empty-p which is introuded in Emacs 28, in "some-program". A user of some-program could then: (with-eval-after-load 'some-program (require 'compat-lib-28)) I am just a bit concerned about all-in approach. As I udnerstand your code, it is loaded as a library, and all code is loaded at once. So there might be code that affects files and naming, or they might be coad that affects displayign of windows, frames or code of handling user input etc. User might not want to load everything and change behaviour of his/her entire Emacs. This might also lead to unnexpected problems when there are 3rd party packages that rely on the old behaviour. I would rather prefer if compat-lib-28.el (or whatver called), would check on it's features it overloads. Easy case is wiith named features. It could check if user has loaded dired, and load it's compatibility functions for dired that were introuded in emacs 28, and it could also put itself in with-eval-after-load statement, so that if some feature is loaded again, it loads itself. Harder is case when library does not export a named feature, like files.el. That would provide for transparent "namespace" handling as you describe in your next paragraph. Of course, newly introduced functions are not the problem; I am concerned with already existing functions, which might have changed slightly how they function. I don't know if such exists, but I am thinking that some code could be broken or still not function, despite function being advised to '28 version'. I think it is important to not load and advise too much. If a program uses only function foo, than there is no need to twinkle with function bar. Another thing I was thinking of is use of advice. Advice is global, it means it affects all users of the function. Isn't it better to define a buffer-local variable, stash old function in the variable, and than call this buffer-local from the compat function. That would also require compat layer to be a minor mode, which is why I call it a layer rather than a library. User would have to do slightly more: (with-eval-after-load 'some-program (require 'compat-lib-28) (compat-mode +1)) That way the risk of conflicts when function has slightly change from it's previous version is minimized since it will run only in that buffer, affecting (hepofully) just 'some-program. Or something ... I don't know; those were just thoughts, maybe I am wrong about. > There still is work to be done, before anything could be added to ELPA, > especially providing tests to ensure that the compatibility layer is > implemented correctly, and making sure that no functions are used that > break the compatibility promise. Ert tests provided in version it provides compatibility for can always be used, when there are some? > So before I continue working on this, I would like to ask if there is > any interest/there are any objections to providing such a library? Why should there be objections? It is free to write a library and give it to the world, right?