From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#25627: 25.1; `help-make-xrefs' loads `cl-extra.el' now Date: Mon, 6 Feb 2017 18:21:54 -0800 (PST) Message-ID: <5f457952-82ca-4a77-8061-1b2e366fcfb2@default> References: <82c8d359-fd05-4bff-9dba-29d2738d435d@default> <87d1euolzv.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1486434191 23622 195.159.176.226 (7 Feb 2017 02:23:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Feb 2017 02:23:11 +0000 (UTC) Cc: 25627@debbugs.gnu.org To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Feb 07 03:23:07 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1cavQv-0005sX-Iu for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Feb 2017 03:23:05 +0100 Original-Received: from localhost ([::1]:51599 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cavR1-0007tw-AM for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Feb 2017 21:23:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cavQu-0007te-Se for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2017 21:23:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cavQs-0003On-71 for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2017 21:23:04 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59989) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cavQs-0003ON-3h for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2017 21:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cavQr-0005B6-UK for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2017 21:23:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Feb 2017 02:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25627-submit@debbugs.gnu.org id=B25627.148643412819827 (code B ref 25627); Tue, 07 Feb 2017 02:23:01 +0000 Original-Received: (at 25627) by debbugs.gnu.org; 7 Feb 2017 02:22:08 +0000 Original-Received: from localhost ([127.0.0.1]:58188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cavPz-00059j-Ou for submit@debbugs.gnu.org; Mon, 06 Feb 2017 21:22:07 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:43371) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cavPx-00059C-Pw for 25627@debbugs.gnu.org; Mon, 06 Feb 2017 21:22:06 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v172LwoI004636 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Feb 2017 02:21:59 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v172LwFO002513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2017 02:21:58 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v172LuOa023153; Tue, 7 Feb 2017 02:21:57 GMT In-Reply-To: <87d1euolzv.fsf@users.sourceforge.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:129048 Archived-At: > > I thought that the point of creating `cl-lib.el' was to give people a > > library of the most-used CL constructs and still let them avoid loading > > all of `cl.el'. If we are, in effect, loading `cl-extra.el' now nearly > > by default then what's the point of separating out `cl-lib.el'? >=20 > AFAIK, the point of cl-lib is to have the CL constructs in a separate > namespace, so that loading cl-lib doesn't change the semantics of > existing code that might not expect it (unlike cl.el). What part of `cl.el' changes the semantics of existing [non-cl.el] code? It too uses prefix `cl-', for exactly the reason of not changing things. OK, there are some aliases, such as `case' for `cl-case'. But I thought that such was the case only for situations where Emacs without cl.el did not have such a function/macro/etc. - such as `case'. It is true that there is also stuff in cl.el that IMO does not belong there, because it is not a Common-Lisp emulation. Stuff like `lexical-let'. Such stuff should be elsewhere. There is also stuff that was misguidely given the `cl-' prefix which has no counterpart in Common Lisp. (I've pointed that out to emacs-devel, but no one seemed to care...) It is also the case that there is stuff that has the same name as Common Lisp stuff but which is a very poor emulation of it and should not use the C-L name. An example is `flet'. This is a really good example of something bad. Its doc string even tells you that if you want something closer to Common Lisp use `cl-flet'. Unlike, e.g., `case' and `cl-case', `flet' is not an alias of `cl-flet' (nor should it be). Aside from such messes (and there are a bunch), I think that cl.el, like cl-lib.el, separates its stuff from non-cl.el stuff in Emacs. I don't think there are cases of changing semantics. (But if there are, those should be fixed.) At any rate, this bug report is about `cl-extra.el'. It has long been considered, rightfully, as _extra_ stuff. (And it is not loaded by loading `cl.el'.) If you take a look at what is in it then I think you'll agree that it is hardly stuff that needs to be loaded by default. And when I say "loaded by default" I speak loosely, including the case of a user using `C-h f' and - whoops! - suddenly cl-extra gets loaded. That should not happen. And it certainly should not happen just because someone wanted to use `cl-some'. That use case is such a trivial one to code in other ways. The only reasons I can think of for someone using `cl-some' here are ignorance (that it is defined in cl-extra.el, laziness, or I-don't-care. > This change was done by [1: 59b5723c9b], the commit message is a bit > terse. But it looks like the idea is to use `describe-symbol-backends' > for this in order to make it extendable, specifically to let cl-extra > add an entry for classes. Yes, I see what `cl-some' is used for, here. But even if one wants to do what is done with `describe-symbol-backends' (which IMO has a bad name and whose addition didn't gain us anything, but that's OK), there is no need to use `cl-some' to do it. One can use `describe-symbol-backends' easily without `cl-some' (as I know you realize). > 1: 2015-07-07 02:14:16 -0400 59b5723c9b613f14cd60cd3239cfdbc0d2343b18 > Add online-help support to describe types To be clear, my objection is not to the change that makes use of `describe-symbol-backends'. It is to the gratuitous use of `cl-some' which pulls in cl-extra by an autoload. No need; not good.