From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master b0042b7: Make CC Mode load cl-lib rather than cl in Emacs 26. Date: Mon, 26 Jun 2017 18:20:37 +0000 Message-ID: <20170626182037.GD2471@acm> References: <20170625140057.23973.37361@vcs0.savannah.gnu.org> <20170625140057.DC363208E3@vcs0.savannah.gnu.org> <20170626163150.GA2471@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1498501371 9978 195.159.176.226 (26 Jun 2017 18:22:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Jun 2017 18:22:51 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 26 20:22:47 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPYeq-0002Ls-C4 for ged-emacs-devel@m.gmane.org; Mon, 26 Jun 2017 20:22:44 +0200 Original-Received: from localhost ([::1]:47971 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPYev-0004TD-M2 for ged-emacs-devel@m.gmane.org; Mon, 26 Jun 2017 14:22:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPYe1-0004SG-2Y for emacs-devel@gnu.org; Mon, 26 Jun 2017 14:21:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dPYdw-00024V-2d for emacs-devel@gnu.org; Mon, 26 Jun 2017 14:21:53 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:43053 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1dPYdv-00024E-RY for emacs-devel@gnu.org; Mon, 26 Jun 2017 14:21:48 -0400 Original-Received: (qmail 89177 invoked by uid 3782); 26 Jun 2017 18:21:46 -0000 Original-Received: from acm.muc.de (p548C6649.dip0.t-ipconnect.de [84.140.102.73]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 26 Jun 2017 20:21:45 +0200 Original-Received: (qmail 2958 invoked by uid 1000); 26 Jun 2017 18:20:38 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.4 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:216007 Archived-At: Hello, Stefan. On Mon, Jun 26, 2017 at 13:56:46 -0400, Stefan Monnier wrote: > > cl-lib doesn't exist in those older Emacsen, neither does it exist in > > XEmacs. So doing what you suggest isn't a sensible thing to do. > Lots of Emacs packages rely on cl-lib while supporting older Emacsen > as well. There are trade-offs, admittedly, but calling it "not > sensible" is like me saying that your choice is ridiculous. > My question was specifically to understand which part of the trade-offs > made you choose one option over the other. When a package relies on another package which is not part of the user's Emacs, that forces that user either to search for and download that other package, or to give up using the first package. Both options are likely to cause irritation and anger. Doing so is unacceptable, IMAO, because it transfers effort from the maintainer to the user. The maintainer should do everything sensible to smooth the way for his users. > >> That would make you free to use any cl-lib functions and macros > >> without having to add matching c--* macros. > > The macros are necessitated by, amongst other things, name changes in > > functions, some of which have had traditionally approved names for > > decades. (I have a copy of the Lisp Machine Manual from the 1980s to > > back this up.) > Many of your c--* macros are there to choose between the `cl` name or > the `cl-lib` name, and every new macro/function you want to use from > cl/cl-lib will require another one of those macros. Yes. One way to reduce this burden would be to make the traditional names of these functions, without the "cl-" prefix, of equal status to those with the prefix. > Using cl-lib unconditionally would eliminate this need. At great cost, as outlined above. > Stefan -- Alan Mackenzie (Nuremberg, Germany).