From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: more on anything.el inclusion
Date: Sat, 10 Jul 2010 21:20:25 +0200 [thread overview]
Message-ID: <87iq4nqh3a.fsf@tux.homenetwork> (raw)
In-Reply-To: AANLkTikdotXNaBFOpTGtWbrPeVRpXQ31KggiW410BoIM@mail.gmail.com
Hope my private mail is clear enough.
I say no more here as i don't want to pollute this mailing list.
MON KEY <monkey@sandpframing.com> writes:
> 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\
>
>
--
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/
next prev parent reply other threads:[~2010-07-10 19:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-10 18:27 more on anything.el inclusion MON KEY
2010-07-10 19:20 ` Thierry Volpiatto [this message]
2010-07-12 13:53 ` Ted Zlatanov
-- strict thread matches above, loose matches on Subject: below --
2010-06-29 12:43 No answer on bugs Thierry Volpiatto
2010-06-30 18:16 ` Ted Zlatanov
2010-06-30 18:36 ` Thierry Volpiatto
2010-06-30 19:23 ` more on anything.el inclusion (was: No answer on bugs) Ted Zlatanov
2010-06-30 20:10 ` more on anything.el inclusion Thierry Volpiatto
2010-06-30 22:59 ` Dan Nicolaescu
2010-07-01 5:53 ` Thierry Volpiatto
2010-07-01 6:48 ` Dan Nicolaescu
2010-07-01 7:50 ` Thierry Volpiatto
2010-07-01 8:36 ` Dan Nicolaescu
2010-07-01 8:53 ` Thierry Volpiatto
2010-07-01 16:02 ` Dan Nicolaescu
2010-07-01 16:33 ` Harald Hanche-Olsen
2010-07-01 16:43 ` Ted Zlatanov
2010-07-01 17:18 ` Thierry Volpiatto
2010-07-01 17:43 ` Dan Nicolaescu
2010-07-01 18:14 ` Thierry Volpiatto
2010-07-01 18:48 ` Ted Zlatanov
2010-07-01 18:57 ` Wojciech Meyer
2010-07-01 17:36 ` Harald Hanche-Olsen
2010-07-01 13:18 ` Ted Zlatanov
2010-07-01 14:15 ` Thierry Volpiatto
2010-07-01 14:48 ` Lennart Borgman
2010-07-01 15:55 ` Ted Zlatanov
2010-07-01 16:43 ` Lennart Borgman
2010-07-01 18:55 ` Ted Zlatanov
2010-07-01 22:08 ` Lennart Borgman
2010-07-09 14:46 ` Thierry Volpiatto
2010-07-17 13:37 ` rubikitch
2010-07-17 15:16 ` Thierry Volpiatto
2010-07-04 22:02 ` Stefan Monnier
2010-07-07 16:47 ` Ted Zlatanov
2010-07-23 15:35 ` Stefan Monnier
2010-07-23 21:49 ` rubikitch
2010-08-12 23:02 ` Ted Zlatanov
2010-08-24 19:24 ` rubikitch
2010-08-25 13:51 ` Juri Linkov
2010-09-11 12:02 ` Thierry Volpiatto
2010-09-11 11:59 ` Thierry Volpiatto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87iq4nqh3a.fsf@tux.homenetwork \
--to=thierry.volpiatto@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).