From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: more on anything.el inclusion Date: Mon, 12 Jul 2010 08:53:18 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87zkxwbycx.fsf@lifelogs.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1278942821 7348 80.91.229.12 (12 Jul 2010 13:53:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 12 Jul 2010 13:53:41 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 12 15:53:39 2010 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.69) (envelope-from ) id 1OYJRy-0002Oc-Ee for ged-emacs-devel@m.gmane.org; Mon, 12 Jul 2010 15:53:38 +0200 Original-Received: from localhost ([127.0.0.1]:56660 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYJRx-0008GY-IR for ged-emacs-devel@m.gmane.org; Mon, 12 Jul 2010 09:53:37 -0400 Original-Received: from [140.186.70.92] (port=51450 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYJRr-0008GT-L5 for emacs-devel@gnu.org; Mon, 12 Jul 2010 09:53:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYJRq-0002rM-GX for emacs-devel@gnu.org; Mon, 12 Jul 2010 09:53:31 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:38986) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYJRq-0002r7-6y for emacs-devel@gnu.org; Mon, 12 Jul 2010 09:53:30 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OYJRo-0002L2-F1 for emacs-devel@gnu.org; Mon, 12 Jul 2010 15:53:28 +0200 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Jul 2010 15:53:28 +0200 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Jul 2010 15:53:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 35 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:VhW7iPvXk1b5r9ioru5XVQRzefk= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:127104 Archived-At: On Sat, 10 Jul 2010 14:27:45 -0400 MON KEY wrote: MK> Maybe Icicles and Antyhing code/features could/should be merged before MK> inclusion in Emacs. MK> FTR I use neither Anything nor Icicles and couldn't endorse either MK> from experience. However, I have watched the progress of their MK> respective development with interest. I used both anything.el and Icicles for a long time (though I stopped using Icicles a year ago). They can't be merged. At best you can pick features from both. MK> It is wrongheaded to arbitrarily incorporate external packages which MK> duplicate existing core behaviour/features such that the duplication MK> of the new (however useful) is better positioned to becomes the norm MK> simply by virtue of the pain imposed on emacs-devels to retrofit a MK> core API after the fact. I disagree with your phrasing ("arbitrarily" and "duplication" in particular) and your conclusions. MK> IOW lets say anything.el were to be included in Emacs and it became so MK> widely adopted that it was deemed worthwhile to attempt a retroactive MK> metaleval API (including C primitives). Were Stefan or some other MK> devel to endeavor implementation of such an API they might be hard MK> pressed to maintain backwards compatibility with the existing MK> anything.el procedures and prob. alienate the primary anything.el user MK> base to boot. Well, that's why I asked Stefan what his decision was. If he says "no" that's fine. I think he can judge the effort and significance of an alternative to the standard completion mechanism. Ted