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 16:05:24 +0200 Message-ID: References: <877dfavmzw.fsf@posteo.net> <87fstyrqj4.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="12230"; 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 16:06:52 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 1mSgQ7-0002u8-4G for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 16:06:52 +0200 Original-Received: from localhost ([::1]:39814 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSgQ5-0004wA-Nl for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 10:06:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42572) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSgOs-0004A6-Nj for emacs-devel@gnu.org; Tue, 21 Sep 2021 10:05:35 -0400 Original-Received: from mail-oln040092070107.outbound.protection.outlook.com ([40.92.70.107]:6157 helo=EUR03-AM5-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 1mSgOo-0001Ak-OA for emacs-devel@gnu.org; Tue, 21 Sep 2021 10:05:33 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UqofUY2biFLZtN7lK28ygYg/kOsQUlNcAAB1VFW40B6mxi5VJXOcHnCOwX3vI/tmFRCt84aUJVWcmStAZBT4AvgEND2/FxZWjYPHx5UNYGxNtvf79vByFTNLGRvbj1pHipX/B+FL3b4NrXdaoCxPfDWrAeBT7jD8YOwz2fH4FwJeVZMV6grsX7sWMHTCQxV5v9Et+HW2LWDS1tY+V8qv4+pBtB8RjetWiJoLt2WyyqQPdZ2J6RNWc6Ftn68YiBx2IcGC+HxaufgrNeNiDzKL1YP9nnq7uURcRzXH7rixQBK3+5WH2iBmTsWTyM0v1zZ/2mtNuZ924IkM4xNj8Y9dJQ== 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=fsnwjw85GogdFgBUstFb0oX4bMokpoSJFDXI9Roi0X8=; b=kNAMloQPi2tbKqTcJQLeiGdioY4yz7sraNNFilWqR/O9xDzNzjEVZNYXXxKv/9eJyDX5wDtzsfjNuWocX3LpmC3ebX8as6TFg0OOEUR727123ws36KzXrTl6NLx67aX/VhYFBlcpFxlEn87R9G1k1K+M58JUxH2P4ck05/DCGZoquHNG7AqMh4HhV1ObCamukavjlZrYxIah/dqpQgaOrgVYxcRrXLjPdhsbN0I4jxiaqGrBIj2hw/brVIi8ZejDCsy6EjT9d+Rs6tci9MJuUBhPESP0pI06liSW48hlO4GbbmHjbI1aNawGDExpUZncUrrCaGl38Q4LcG88JIb2WA== 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=fsnwjw85GogdFgBUstFb0oX4bMokpoSJFDXI9Roi0X8=; b=NeCREi1zFZ224T4Dd1857D8Zs6gpg+tc5i6jK0FZuGllHdAPaw7ebBbIAxa6unYas3LbsUVAQ4s3Fbr8IOnpXj+sk4SIuB9tKxq5411eFx5cpSHGfzJIUXZ1HRqAiPBtYrMWCNWEmvEry7XDRtgJzKxzgtSq8KnV1qf5d0Hnjv+R8MJ0TmBZRvLdSbrqdpAios1Xv9CqDK2cp4bhjsTDGVNxOOXggy3yOa5UVv1XObyHpTiB5ixH/0H9VsmV2oJp5rFRy0pDlSbKW+1UBoFj30jbzEO2khjieJCDsRGWMykj1eu7jtOZj6G37i3K0Ftvi/mVtbKNXTAFnfbMPTbKGw== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by AM0PR09MB2529.eurprd09.prod.outlook.com (2603:10a6:208:dc::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.17; Tue, 21 Sep 2021 14:05: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 14:05:25 +0000 In-Reply-To: <87fstyrqj4.fsf@posteo.net> (Philip Kaludercic's message of "Tue, 21 Sep 2021 13:45:19 +0000") X-TMN: [eZgrQ3qhH/ETDxLz1uoRbxpLGuOY+DMb] X-ClientProxiedBy: HE1PR05CA0167.eurprd05.prod.outlook.com (2603:10a6:3:f8::15) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <87o88mqb17.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from pascal.homepc (81.232.177.30) by HE1PR05CA0167.eurprd05.prod.outlook.com (2603:10a6:3:f8::15) 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 14:05:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 57f75cc4-7c08-4867-9def-08d97d08dc12 X-MS-TrafficTypeDiagnostic: AM0PR09MB2529: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: wibD+Vd0siA4z60TZPeZw02EGDqyfXCP9phRgTbs/F84ZwyEu/vn5OPO/tmffsr5GEcFFskSGT64laLvI6xdy6IEsqXd71G5WePGawUPAIk1hwadd6vhP8SeWT0w5F1JENuS6CVM4NHEMXiQDi1V0vV2TxpJnUH8guJPZrkXFJz8Z2ri+fgriq0H4BpXv1vNtIdeoZF84x/12ETZYD5D8MnBgasuFqnW8y4OxDcZffVwpjWnL4O51r9uX04HxDFBJCl0OLz36KGcz3OyOoAw1RHCboc9//PPvJP/TxR5pdovxOo4kaw4SWS5ZLce4CWvBJHjVbUTHZA0VLraAQlA6Lyap0og/Mq0dp7pL/vXSBG/Ajm27qD2cvAGHrE95N6RpsYhxFyqmxKk3YeJRW/sqLisgvdEybLgp1IpUAbSxwC8kXmqt4XAaKz2LiJ5Sugd X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: qi3/26MR9m1S9/kyJ/tRWbUBrIpkVmpFESS3eP77aVTv5lPXxAOTTzzYKYwI9cqKdnf8fRQHkX8KNocF9tQzJE4H2y0WOJogMsT0fuTZf4SATdYw9EIJbcGf+woTmoUccD3zYwJ0iDEdN5bwJYkb9A== X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-72e6e.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 57f75cc4-7c08-4867-9def-08d97d08dc12 X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2021 14:05:25.9036 (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: AM0PR09MB2529 Received-SPF: pass client-ip=40.92.70.107; envelope-from=arthur.miller@live.com; helo=EUR03-AM5-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:275241 Archived-At: Philip Kaludercic writes: > Arthur Miller writes: > >> 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". > > Just to clarify: My point is that I *don't* want to just propose a > different dash/s/f/... library, that consists of only a few new useful > functions and macros. Yes I understand that your point wasn't to create another s.el, but I didn't understand from your mail why would that be a bad thing :). I was just refering to your rhetorics: what is wrong with s, dash? They do well what they do. That does not mean that I suggest you should do another "s.el"; I was just trying to talk about it in general. I don't By the way, uour library would not be "another s, dash ..." per definition :). You don't do what they do; and Can we talk about things in general? So I don't see why bringing in s, dash and other in this as they were a bad thing? >>> 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)) > > Why would a user do this? Because the user runs older Emacs and all the 3rd party packages that might be affected by an advised function with possibly changed behaviour. So user can verify it works or not and developer does not need to burden itself with different execution paths, which in long run makes code that is easir to understand and maintain. >> 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. > > The audience of this library are developers, not (non-developer) > users. The point is not to make older versions of Emacs work like 28 or > newer, but to make code that targets Emacs 28 work with older versions > (insofar this is possible). Yes, I understood that, and the problem is not when you provide new functions, but when existing functions are slightly changed. As a developer it can be very hard to know how it will affect some 3rd party package in some older version. Developers would have to test in old versions as well etc. I would really dislike Lisp code to look like C code we seen in Emacs src; those if-defs are really nasty sometimes. >> 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. > > I agree, it might make sense to remove some of the compatibility > definitions, that just supply an additional argument. I'd argue there > are cases where it makes sense, such as assoc and the testfn argument, > but they have to be evaluated. > >> 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. > > A different idea might be to try an integrate the compatibility layer > into the byte-compilation process for specific files. But once again, > this wouldn't be done by the user, but a (package) developer would > request for it to be done. Indeed, but sounds like a labourous thing to implement. You could also do something similar if you checked at package installation what a packages uses and installed a compat layer, but it seems like a lot of work and an unreliable approach. Both approaches would have to patch code in old Emacs (byte compiler or package.el). Would be cool thing to see if you manager ot pull it off, but I think it is a lot of work. >>> 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? > > I know, I am currently working on writing a test suite with ert. > >>> 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? > > Yes, but I respect the opinion of the list and would like to add this to > ELPA, so good objections could change my mind that it is worthwhile to > implement something like this to the end. Yes of course. I am not sure if mine are very good, but, good luck, I hope you get something that works.