From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: How to find when a feature was introduced Date: Fri, 8 Jul 2016 16:40:43 +0000 (UTC) Message-ID: <80bd016a-346f-4a32-bfe7-33b4b374d77e@default> References: <1467953596.3500300.660244737.0CDCE013@webmail.messagingengine.com> <6a92cb61-53ac-4538-a0ac-5873851bdc85@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1467996107 21144 80.91.229.3 (8 Jul 2016 16:41:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Jul 2016 16:41:47 +0000 (UTC) To: Paul Rankin , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jul 08 18:41:35 2016 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bLYqM-0003pE-PG for geh-help-gnu-emacs@m.gmane.org; Fri, 08 Jul 2016 18:41:35 +0200 Original-Received: from localhost ([::1]:46781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLYqM-0003HC-6n for geh-help-gnu-emacs@m.gmane.org; Fri, 08 Jul 2016 12:41:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60816) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLYpf-0003F1-MT for help-gnu-emacs@gnu.org; Fri, 08 Jul 2016 12:40:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLYpc-0001Cp-AF for help-gnu-emacs@gnu.org; Fri, 08 Jul 2016 12:40:51 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:46561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLYpc-0001Cc-1m for help-gnu-emacs@gnu.org; Fri, 08 Jul 2016 12:40:48 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u68GejZ5021351 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2016 16:40:45 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u68GejhG015691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2016 16:40:45 GMT Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u68GeiTv016723; Fri, 8 Jul 2016 16:40:44 GMT In-Reply-To: <6a92cb61-53ac-4538-a0ac-5873851bdc85@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:110735 Archived-At: > I see too many libraries (IMHO) that evolve to gratuitously use > recent constructs, which means some of their users can lose the > possibility of using them. >=20 > By "gratuitously" here I mean that the library maintainer and the > library itself do not really gain anything important by such a > change. Obviously, if a new feature enables you to do something > really different (e.g. bidi support) or really better, then there > is no reason not to take advantage of it. >=20 > But many changes I see are little more than cosmetic, and if such > a case throws library users by the wayside then I think that's a > waste. On the other hand, it can make things easier for a library > maintainer not to have to worry about supporting more than the > latest release... And to circle back to the original question and its use case: Choosing to use macro `with-eval-after-load' instead of function `eval-after-load' is a good example of an evolution for a library to undergo that is often essentially gratuitous, IMO. If there is another, better or significant reason to require a version of Emacs that is recent enough that it includes `with-eval-after-load', then using that macro is _not_ just gratuitous. But on its own, as the sole reason for requiring that recent a version of Emacs, it is likely to be so. Here is the definition of macro `with-eval-after-load': (defmacro with-eval-after-load (file &rest body) `(eval-after-load ,file (lambda () ,@body))) It just wraps the BODY in a lambda and calls `eval-after-load'. The lambda form is funcalled after FILE is loaded. Why was this macro added to Emacs? (Its addition was a good thing, BTW.) (1) Because the most common use case of `eval-after-load' passes a quoted sexp as the BODY, and some users were leaving off the quote and then wondering why their code did not work. And (2) because a quoted BODY returns a sexp, and that sexp (to be evaluated later as code) is just constant _data_ at compile time; it is not byte-compiled as code. Both are good reasons for adding `with-eval-after-load' to Emacs. Are they good reasons for replacing `eval-after-load' in your library? IMO it depends on (a) whether byte-compiling the particular BODY form really makes a difference for your code and, if not, (b) whether there is anyway another reason for the library to be usable only with an Emacs version that is recent enough to have `with-eval-after-load'. (And for (a), if the BODY sexp is complex enough that you care about it being compiled, it is usually enough to just=20 define a function that encapsulates that sexp, and use the function name as BODY. The function definition is compiled.) This macro was introduced in Emacs 24.4. And immediately, I suspect, libraries all over the place started using it, even sometimes replacing correct uses of `eval-after-load'. Are all such updates needed? useful? Are some of them what I would call gratuitous? My own approach is to require Emacs 24.4 or later only when the code in my library really needs it or can really take advantage of it. I generally would not do that just to be able to use macro `with-eval-after-load'. As usual, it's a tradeoff: Do you want users with an older Emacs version to be able to use your library? Do you want to take advantage of what the new feature (macro, in this case) offers? Sometimes a new library starts out more or less as a set of personal Emacs customizations. In that context, the library author typically does not care about supporting versions of Emacs older than the one s?he uses. And that unconcern for older-version use can then become a habit. And it certainly is easier, in terms of maintenance. I think this explains most lack of support for multiple Emacs versions. --- There is also this consideration, BTW, from (elisp) `Coding Conventions', but it is orthogonal to my point here. Avoid using 'eval-after-load' and 'with-eval-after-load' in libraries and packages (*note Hooks for Loading::). This feature is meant for personal customizations; using it in a Lisp program is unclean, because it modifies the behavior of another Lisp file in a way that's not visible in that file. This is an obstacle for debugging, much like advising a function in the other package. That is of course reasonable advice, though it simplifies and overstates the case. Running a hook, in this case after loading a Lisp file, does _not_ necessarily modify the behavior of that file. What is true is that whatever the hook function does is not something that is visible in that Lisp file. It's OK - that text is not bad. But it is a case of a=20 recommendation in the doc that you want to _understand_ and not just take literally as gospel.