From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: elib -> emacs Date: Tue, 19 Jun 2007 14:45:13 +0200 Message-ID: <86ejk8ru3q.fsf@lola.quinscape.zz> References: <200706160029.l5G0Tv318102@f7.net> <200706181008.04551.andreas.roehler@online.de> <200706191428.11828.andreas.roehler@online.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1182257127 3251 80.91.229.12 (19 Jun 2007 12:45:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 19 Jun 2007 12:45:27 +0000 (UTC) Cc: Nick Roberts , Karl Berry , rms@gnu.org, emacs-devel@gnu.org To: Andreas =?iso-8859-1?Q?R=F6hler?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 19 14:45:22 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I0d5E-0005lv-91 for ged-emacs-devel@m.gmane.org; Tue, 19 Jun 2007 14:45:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I0d5D-00018Y-SR for ged-emacs-devel@m.gmane.org; Tue, 19 Jun 2007 08:45:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I0d5B-00017X-7m for emacs-devel@gnu.org; Tue, 19 Jun 2007 08:45:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I0d5A-00016d-PX for emacs-devel@gnu.org; Tue, 19 Jun 2007 08:45:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I0d5A-00016L-HT for emacs-devel@gnu.org; Tue, 19 Jun 2007 08:45:16 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I0d58-0001jU-LZ for emacs-devel@gnu.org; Tue, 19 Jun 2007 08:45:16 -0400 Original-Received: from quinscape.de (dslnet.212-29-44.ip210.dokom.de [212.29.44.210] (may be forged)) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id OAA27363 for ; Tue, 19 Jun 2007 14:45:08 +0200 X-Delivered-To: Original-Received: (qmail 24785 invoked from network); 19 Jun 2007 12:45:13 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 19 Jun 2007 12:45:13 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 8C7D08EA27; Tue, 19 Jun 2007 14:45:13 +0200 (CEST) In-Reply-To: <200706191428.11828.andreas.roehler@online.de> ("Andreas =?iso-8859-1?Q?R=F6hler=22's?= message of "Tue\, 19 Jun 2007 14\:28\:11 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:73301 Archived-At: Andreas R=F6hler writes: > Am Dienstag, 19. Juni 2007 12:41 schrieb Richard Stallman: >> I presume that tar file is the distribution of our elib package. >> It is not part of Emacs. The question is what parts of it to merge >> into Emacs. >> > > My attention here results from the package as such and > an impression, it would be helpful for > elisp-programmers to have collections of > general-purpose resources. > > For novices this might be of special interest. > Currently general-purpose functions are written again > and again, because existing are scattered and people > ignore them. See already mentioned string-strip > facilities. The solution cannot be to write even more of such functions and scatter them into libraries with separate documentation and interfaces. Consolidation should happen into the existing subr.el, with documentation in the normal Elisp manual. > In this context also the different name of already merged > functions matters: > > elib's `string-replace-match' AFAIU is easier to call > and remember than the (slightly changed) > `dired-string-replace-match' now in dired.el. That can't be a reason to introduce a new function under a new name if the functionality is basically the same. If cleanup, reorganization and similar janitorial work is required (which may very well be the case), it should not be done by heaping cleaner code on top of existing ugliness. We need fewer possibilities to do the same thing, not more. I cannot see (judging from current postings rather than actually looking at the code) that adding elib as a separate entity is going to help consolidating this situation. It very much sounds like the way to go about this would be to check whether we can get papers for it, and if we can, break it down for reusable pieces that we pull into subr.el and the Elisp manual. Probably the main work would be finding and replacing prospective callers and duplicate functions. --=20 David Kastrup