Re: more on anything.el inclusion

[MON KEY <monkey@sandpframing.com>]

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\