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 15:15:16 -0800 (PST) Message-ID: References: <20160222175244.30186.2617@vcs.savannah.gnu.org> <87k2lwv5ob.fsf@gmx.de> <87egc4v4hs.fsf@gmx.de> <8bd4ec21-1306-41bf-aca7-5571a3014337@default> <87r3g4js64.fsf@gmail.com> 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 1456182957 24159 80.91.229.3 (22 Feb 2016 23:15:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Feb 2016 23:15:57 +0000 (UTC) Cc: Michael Albinus , Stefan Monnier , Emacs developers To: Oleh Krehel , Kaushal Modi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 23 00:15:44 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 1aXzhf-0004Rd-Bc for ged-emacs-devel@m.gmane.org; Tue, 23 Feb 2016 00:15:43 +0100 Original-Received: from localhost ([::1]:52609 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXzhe-0003wp-EE for ged-emacs-devel@m.gmane.org; Mon, 22 Feb 2016 18:15:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXzhO-0003wd-Hc for emacs-devel@gnu.org; Mon, 22 Feb 2016 18:15:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXzhK-0006Ei-Hb for emacs-devel@gnu.org; Mon, 22 Feb 2016 18:15:26 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:41143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXzhK-0006Ed-An for emacs-devel@gnu.org; Mon, 22 Feb 2016 18:15:22 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1MNFJFp012105 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Feb 2016 23:15:19 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1MNFIRA009866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Feb 2016 23:15:18 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1MNFI6w025496; Mon, 22 Feb 2016 23:15:18 GMT In-Reply-To: <87r3g4js64.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] 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:200508 Archived-At: > > +1 > > > > I wholeheartedly agree to that. >=20 > +1 from me as well. I recall recently Richard proposed that we vote on > some new isearch feature. Should we vote on renaming `cl-caddr' -> > `caddr' as well? >=20 > Here's a list of `cl-' stuff that I like to use, which I think wouldn't > bring confusion without a `cl-' prefix: `cl-find-if', > `cl-remove-if-not', `cl-incf', `cl-position-if', `cl-caadr', > `cl-rotatef', `cl-destructuring-bind'. >=20 > I realize there are prefix-less aliases for most of these functions. > But I'm not sure how long they're staying. And if they are staying > indefinitely, is there a reason to use `cl-' prefix? I made a switch to > the prefix some time ago when the unprefixed macros became no longer > syntax-highlighted. But now since recently all macros are syntax > highlighted, no matter where they come from. I understand that we like using library prefixes (I respect that), hence the use of `cl-'. But there is plenty in Emacs that is just plain _Lisp_, and which is not different between Common Lisp and anything else that Emacs has. Emacs Lisp has just as much a right to these Lisp names as any other Lisp. We don't say `subr-rplacd' just because `rplacd' is defined in `subr.el'. And we have plenty of functions and macros that are not found in other Lisps. Many of those too are in files that are not considered to be foreign libraries but, like `subr.el', are simply part of the Emacs-Lisp language. We don't say `simp-goto-line' just because `goto-line' is defined in `simple.el'. And we don't say `diraux-dired-do-chmod' just because `dired-do-chmod' is defined in `dired-aux.el'. Why should we act differently when it comes to things like `caddr'? Regardless of what file they are in, and whether that file is loaded by default (like `simple.el' and `subr.el') or only on demand (like `dired-aux.el), I see no good reason for such things to be plastered over with a `cl-' prefix. In a way this is a minor, bike-shed point. And in a way it is anything but bike-shedding. To me, it is just common sense to use widespread, longstanding Lisp names as is, without embellishment. Unless, that is, there is an Emacs-Lisp version that already has the unembellished name and is different. In the relatively few cases where Emacs Lisp has its own, different thing that has a widespread Lisp name, using the `cl-' prefix for the Common Lisp emulation is appropriate. And that makes the difference stand out: This thingy with the `cl-' prefix is different from the similarly named thingy without that prefix. Finally, to make things even more muddy, we have recently piled additional, non-Common Lisp stuff into the `cl-' namespace. What's that about? That just confuses people. If it's just because such things are in a `cl*.el' file then I think we're missing the point of such a prefix. It should be reserved for Common Lisp emulation, nothing more or less.