From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification Date: Mon, 22 Feb 2016 13:39:01 -0800 (PST) Message-ID: <8bd4ec21-1306-41bf-aca7-5571a3014337@default> References: <20160222175244.30186.2617@vcs.savannah.gnu.org> <87k2lwv5ob.fsf@gmx.de> <87egc4v4hs.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1456177190 31487 80.91.229.3 (22 Feb 2016 21:39:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Feb 2016 21:39:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Albinus , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 22 22:39:38 2016 Return-path: Envelope-to: ged-emacs-devel@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 1aXyCf-00034o-R0 for ged-emacs-devel@m.gmane.org; Mon, 22 Feb 2016 22:39:37 +0100 Original-Received: from localhost ([::1]:52195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXyCf-0001gq-BV for ged-emacs-devel@m.gmane.org; Mon, 22 Feb 2016 16:39:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXyCS-0001gj-JO for emacs-devel@gnu.org; Mon, 22 Feb 2016 16:39:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXyCM-00057g-5Z for emacs-devel@gnu.org; Mon, 22 Feb 2016 16:39:24 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:23738) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXyCL-00057X-Vh for emacs-devel@gnu.org; Mon, 22 Feb 2016 16:39:18 -0500 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 u1MLdDe1024294 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Feb 2016 21:39:13 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1MLdDOW008330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Feb 2016 21:39:13 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1MLd2Q2019407; Mon, 22 Feb 2016 21:39:07 GMT In-Reply-To: <87egc4v4hs.fsf@gmx.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.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: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:200504 Archived-At: > >> filenotify.el:470:1:Warning: the function =E2=80=98caadr=E2=80=99 is n= ot known to be > >> defined. > > > > Well, of course: all cl-lib definitions use the "cl-" prefix. >=20 > Hmm, yes. Somehow I'm always unable to remember proper use of cl and > cl-lib :-( It's insane that Emacs now calls these `cl-caddr' etc., instead of calling them `caddr' etc. like all other Lisps (those that have them) - including Emacs prior to this renaming. Hard to believe this actually went down. Take a simple, longstanding naming convention designed to be as succinct and transparent as possible, and coat it in a thick layer of sticky, gooey mucilage... ("What were they thinking?") There is nothing particularly *Common*-Lispy about these functions. It's not like there was some conflict with other, Emacs-Lisp `caddr' etc. functions. What's next, `cl-setq'? `cl-let'? `cl-car'? (No, not a joke - `caddr' is no more Common-Lispy than are `setq', `let', and `car'.) I suppose someone could argue that this ugliness might dissuade people from using these functions. Hopefully such dissuasion will work in favor of using context-specific access functions or macros, or better structuring code.