From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Proposal: Forwards-Compatibility Library for Emacs Date: Tue, 21 Sep 2021 13:45:19 +0000 Message-ID: <87fstyrqj4.fsf@posteo.net> 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="29419"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 21 15:47:10 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 1mSg74-0007RF-31 for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 15:47:10 +0200 Original-Received: from localhost ([::1]:43186 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSg72-00040v-1q for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 09:47:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34490) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSg5P-0002dZ-Hh for emacs-devel@gnu.org; Tue, 21 Sep 2021 09:45:27 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:47897) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSg5L-0007x0-Of for emacs-devel@gnu.org; Tue, 21 Sep 2021 09:45:26 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 15590240106 for ; Tue, 21 Sep 2021 15:45:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1632231921; bh=Q6f85hHtRL4PjSh3POdnqValDTzQsKi1V0yC3yQ4SyE=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=Sq19h6ru8H1VAOjMUs/s/VvBccuxV+oOimddgpbaIZDSFMTI4Y+r87Lg0OryVp+Mf iTcn4iD7wVyDpiat+a+xXBbYs9ClesQJ2pnY7uKlARkf7DXgaFo5e1MrJmbe7glbfw OcGoN7FJeX0ZLAGnIUEVSLnuIhMAbQiJ10ycjgdgKe6LJCytgv7LB9dhidTHLalMJt yoEHU8KaR0jI3Jkj3Ozfq6UWsqtq44MieHbTDkslBd1JK3OkzwGfqJG66WDYSWix/e LfZn4b9SkcP3spxfVzQJwXJiFkOwThLfn+E/rpaNZZ3mOxhwliCc0b9SbCU4FDz7dc eSxlBWKYdAYPg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4HDN3N0QPcz9rxj; Tue, 21 Sep 2021 15:45:19 +0200 (CEST) Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB In-Reply-To: (Arthur Miller's message of "Tue, 21 Sep 2021 15:27:24 +0200") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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:275234 Archived-At: 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. >> 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? > 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). > 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. >> 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. -- Philip Kaludercic