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, 29 Feb 2016 13:19:21 -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> <2b98a5dd-7f46-4e92-9398-ede070c261de@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 1456780790 8256 80.91.229.3 (29 Feb 2016 21:19:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Feb 2016 21:19:50 +0000 (UTC) Cc: Emacs developers , John Wiegley , Michael Albinus , Oleh Krehel , Kaushal Modi To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 29 22:19:35 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 1aaVE7-00088e-7e for ged-emacs-devel@m.gmane.org; Mon, 29 Feb 2016 22:19:35 +0100 Original-Received: from localhost ([::1]:39206 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaVE6-0004qt-JZ for ged-emacs-devel@m.gmane.org; Mon, 29 Feb 2016 16:19:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaVE3-0004qW-0Z for emacs-devel@gnu.org; Mon, 29 Feb 2016 16:19:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaVDz-0000Hx-Py for emacs-devel@gnu.org; Mon, 29 Feb 2016 16:19:30 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:47365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaVDz-0000Ht-JP; Mon, 29 Feb 2016 16:19:27 -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 u1TLJOJ6022127 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Feb 2016 21:19:25 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 u1TLJNkc012160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Feb 2016 21:19:24 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1TLJMh7007242; Mon, 29 Feb 2016 21:19:22 GMT In-Reply-To: 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:200825 Archived-At: > > `cl-callf' > > `cl-callf2' >=20 > Don't have an opinion on those two. They might fit in gv.el. Good. > > `cl-iter-defun' >=20 > This one could indeed move to generator.el, tho it currently uses > the internal cl--transform-lambda, so the implementation would need > to be rewoked to avoid having an external package depend on CL's > internals. Good again. > > `cl-flet*' >=20 > This belongs right next to cl-flet, so moving it out of cl-lib would > make no sense. >=20 > > `cl-letf*' > > This belongs right next to cl-letf. It belongs right next to `letf'. Neither `letf' nor `letf*' are Common Lisp. Why should they be in this library and have prefix `cl-'? They are Emacs inventions. > > `cl-prettyprint' (called a "debugging aid") > > `cl-prettyexpand' (called a "debugging aid") > > `cl-describe-type' >=20 > These are intimately linked to cl-lib's implementation, AFAIK. 1. No, I don't think so, at least not the pretties. Grepping for `cl-prettyprint' shows that it is used only in `cl-prettyexpand'. =20 Grepping for that shows that it used nowhere. 2. But if it were true then they should use prefix `cl--', no? 3. Grepping for `cl-describe-type' shows that it is used only to fill `describe-symbol-backends' and to define button type `cl-help-type'. Not Common Lisp at all - just Emacs stuff. > > Moving to `cl-preloaded.el': > > `cl-struct-define' >=20 > Same here. IOW they belong to cl-lib not because they're part of > Common-Lisp, but because they belong to cl-lib's implementation. Rename it (there is no "them") using prefix `cl--', if it is really used only to implement a Common Lisp construct. > > And it seems that there are internal functions and macros, > > which are used only for implementing CL things, which use > > prefix `cl-' instead of `cl--'. For example, `cl-struct-define'. > > Should they not be renamed? >=20 > I don't have a strong opinion on this. The issue is the following: > cl-struct-define is "used internally by cl-defstruct", but it can't > be changed at will, because it will basically have to be preserved > for as long as Emacs-NN.MM wants to be able to run .elc files > generated with Emacs-24.5. At the rate things have been changing in the byte-compiler, that won't be long. ;-) > Those "functions only used in a macro's expansion" have a half-way > "internal" status in this respect, and we sometimes give them > a "prefix-" and sometimes a "prefix--". How so, "half-way"? When is it sometimes this and when sometimes that? I think Joost expressed the point pretty clearly just now: To me, `cl' is so obviously an abbreviation for Common Lisp that I would automatically expect any function (macro, etc.) prefixed with `cl-' to be a Common-Lisp emulation function. The fact that some of them aren't is quite confusing and makes me wonder by what=20 criterion a function or macro is included in (or excluded from) cl-lib.