From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Martin Stjernholm Newsgroups: gmane.emacs.devel Subject: Re: cc-langs.el Date: Sat, 23 Aug 2003 15:41:52 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5b7k547aov.fsf@lister.roxen.com> References: <5bekzd29w7.fsf@lister.roxen.com> Reply-To: bug-cc-mode@gnu.org NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1061650784 8752 80.91.224.253 (23 Aug 2003 14:59:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 23 Aug 2003 14:59:44 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Aug 23 16:59:42 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19qZri-0006nR-00 for ; Sat, 23 Aug 2003 16:59:42 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19qZwO-0005QZ-00 for ; Sat, 23 Aug 2003 17:04:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19qZnk-0003ls-7B for emacs-devel@quimby.gnus.org; Sat, 23 Aug 2003 10:55:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19qZ80-0002fD-Cn for emacs-devel@gnu.org; Sat, 23 Aug 2003 10:12:28 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19qZ7C-00026Z-Ig for emacs-devel@gnu.org; Sat, 23 Aug 2003 10:12:10 -0400 Original-Received: from [194.52.182.190] (helo=mail.roxen.com) by monty-python.gnu.org with esmtp (Exim 4.20) id 19qZ3y-0007GV-TC; Sat, 23 Aug 2003 10:08:19 -0400 Original-Received: by mail.roxen.com (Postfix, from userid 52) id 970919A13; Sat, 23 Aug 2003 15:41:54 +0200 (MEST) Original-Received: from lister.roxen.com (lister.roxen.com [194.52.182.147]) by mail.roxen.com (Postfix) with ESMTP id 2DAA799CC; Sat, 23 Aug 2003 15:41:52 +0200 (MEST) Original-Received: from mast by lister.roxen.com with local (Exim 3.36 #1 (Debian)) id 19qYeO-0001E0-00; Sat, 23 Aug 2003 15:41:52 +0200 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Sat, 23 Aug 2003 00:01:05 -0400") User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/20.7 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:16104 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:16104 Richard Stallman wrote: > [CL] functions are not a part of the Emacs Lisp namespace. > (And I don't want to add them and make the Lisp manual much bigger.) I gather your reasoning is: They don't have a namespace prefix and hence they are in the Emacs Lisp namespace, and all functions in the Emacs Lisp namespace must be documented in the elisp manual. Considering the complexity of many elisp applications there's clearly a lack of basic utility functions in the elisp core, specifically functions to operate on the built-in data types, e.g. the map, search and replace functions in the CL package. There are many severe drawbacks when every package with the need have to avoid or reimplement them. Those drawbacks are so basic that I don't think I have to elaborate on that. So why shouldn't Emacs provide that functionality? Because of the size of the manual? That's imho an odd priority, especially considering that the navigational aids provided by Info and other browsing tools easily can handle documentation of at least ten times the size of the elisp manual. Regarding the issue that Miles Bader raised: I don't request that the entire CL library is "blessed"; I'm only talking about the functions that operate on data, i.e. the things in cl-extra.el, cl-seq.el and most of cl.el. Afaik they do their job well (or can at least be fixed to do it well, as there aren't any basic design issues that they try to cover up). The other more questionable stuff could very well remain deprecated.