From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: more on anything.el inclusion Date: Sat, 10 Jul 2010 14:27:45 -0400 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1278786481 27384 80.91.229.12 (10 Jul 2010 18:28:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 10 Jul 2010 18:28:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: tzz@lifelogs.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 10 20:28:00 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 1OXemM-0001hK-V5 for ged-emacs-devel@m.gmane.org; Sat, 10 Jul 2010 20:27:59 +0200 Original-Received: from localhost ([127.0.0.1]:45677 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OXemM-0000tk-39 for ged-emacs-devel@m.gmane.org; Sat, 10 Jul 2010 14:27:58 -0400 Original-Received: from [140.186.70.92] (port=58585 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OXemC-0000rS-Ke for emacs-devel@gnu.org; Sat, 10 Jul 2010 14:27:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OXemB-0006Xr-CV for emacs-devel@gnu.org; Sat, 10 Jul 2010 14:27:48 -0400 Original-Received: from mail-yx0-f169.google.com ([209.85.213.169]:59568) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OXemB-0006Xj-AF for emacs-devel@gnu.org; Sat, 10 Jul 2010 14:27:47 -0400 Original-Received: by yxj4 with SMTP id 4so895442yxj.0 for ; Sat, 10 Jul 2010 11:27:46 -0700 (PDT) Original-Received: by 10.150.13.18 with SMTP id 18mr3501954ybm.198.1278786465403; Sat, 10 Jul 2010 11:27:45 -0700 (PDT) Original-Received: by 10.151.98.19 with HTTP; Sat, 10 Jul 2010 11:27:45 -0700 (PDT) X-Google-Sender-Auth: 1_015u6eHobDUfNAaoNPh5heFyg X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:127004 Archived-At: On Wed, 07 Jul 2010 11:47:40 -0500 Ted Zlatanov wrote: > Does this mean you'd rather not include anything.el in Emacs? > > My view is that the anything.el system, separated from the Emacs > completion mechanism, has significant freedom with plugins and This freedom isn't of itself a good thing and could just as well serve as a potential source confusion/bugs/conflict. AFAIK anything is currently maintained by a cadre of users and the `freedom' that the anything interface provides has/can created conflicts w/re implementation details. Were anything.el to be included in Emacs who would be the lead point of contact? IMHO of the anything cadre Thierry is prob. the capable person, though I imagine nominating him as such could be a bone of contention other of the existing contributors. This being said, it likewise isn't at all clear how/why the Anything featureset is different from or somehow 'better than' the Icicles features Drew Adams' has provided and maintained for many years now. Indeed, IIUC there is already some overlap between the two API's because there a not insignificant degree of functionality overlap. It would seem a real shame (and prob. an insulting to Drew) to consider inclusion of Anything without an honest discussion of inclusion of Icicles as well. Maybe Icicles and Antyhing code/features could/should be merged before inclusion in Emacs. FTR I use neither Anything nor Icicles and couldn't endorse either from experience. However, I have watched the progress of their respective development with interest. > functionality. So improving the completion mechanism is not the > same as what anything.el can provide for Emacs users. Why should it be? What Stephan proposes is absolutely TRT for users such as myself who _could/should_ benefit from the features and proven design concepts which both Anything and Icicles seem to extend to their current adoptees. Why shouldn't we all benefit from an abstracted meta-level API? It is wrongheaded to arbitrarily incorporate external packages which duplicate existing core behaviour/features such that the duplication of the new (however useful) is better positioned to becomes the norm simply by virtue of the pain imposed on emacs-devels to retrofit a core API after the fact. IOW lets say anything.el were to be included in Emacs and it became so widely adopted that it was deemed worthwhile to attempt a retroactive metaleval API (including C primitives). Were Stefan or some other devel to endeavor implementation of such an API they might be hard pressed to maintain backwards compatibility with the existing anything.el procedures and prob. alienate the primary anything.el user base to boot. > Ted -- /s_P\