RE: propose adding Icicles to Emacs

["Drew Adams" <drew.adams@oracle.com>]

> > Icicles has many different features, including the following
> > (in addition to what was mentioned above about Info `i'):
>
> What exactly _is_ icicles, in one sentence?
> It's kind of hard to tell exactly from your post,

It should not be hard to tell. I listed the main features explicitly, point
by point - just after the sentence you quoted. Which ones do you have
trouble understanding?

> but my guess from reading your message: "It extends
> emacs completion in various handy ways".

If you have to boil it down to one sentence, that's as good as any.

The various completion enhancements are largely independent, but they work
well together. For instance, I wouldn't want candidate cycling without also
having regexp or substring matching, to narrow the match set before cycling.
It is the combination that makes it feasible to work with large candidate
sets and still cycle among those that are of interest.

But certainly those two features are relatively independent logically. You
could offer them separately - but I will not.

What would you say to someone who asks, "What exactly is incremental search,
anyway?" You could say "it lets you search incrementally", but that doesn't
help. I would list a few isearch features to describe it, wouldn't you? That
list might include: (1) typing changes are reflected, on the fly, in an
updated search hit list, and the cursor is moved to the new first hit, (2)
all hits are highlighted (lazily), (3) search wraps around, (4) C-g abandons
match failure, and so on. The various isearch features are relatively
independent, but they work well together, and I wouldn't want isearch
without all of them.

Boiling everything down to one sentence is a bit like saying that Emacs is
an extensible, customizable text editor, or that it extends editing and
programming "in various handy ways". Such descriptions don't help much, I'm
afraid.

To get an idea about Icicles, you need to either read something about it or
give it a try. I claim it has a lot to offer and merits a sincere
examination, not just a superficial dismissal. Disagree, if you like, but
after informing yourself a bit, please.

There is plenty of doc describing what Icicles is and what features it
offers, at http://www.emacswiki.org/cgi-bin/wiki/Icicles. I provided a
summary in my proposal message, and the doc starts out with a quick tour
that highlights the main features with examples of use:
http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Nutshell_View.

> However, it also sounds like there are a bunch of other
> unrelated features,

Unrelated in the sense of logical independence, yes. Unrelated in the sense
of not fitting together or supporting each other, no. Just like the isearch
features.

About the only hard dependencies among the Icicles features are these:

1. Progressive completion (matching with multiple patterns, to narrow
candidates down progressively) depends logically on something like regexp or
substring matching, because there is little sense in using multiple prefix
patterns.

2. The multi-command feature depends on being able to cycle among
candidates. This is not a hard dependency, since one could be limited to
clicking the mouse on individual candidates, but in practice cycling is
central to the use of multi-commands.

3. Icicles search, which is a different approach to incremental search and
replace, uses the multi-command feature. So does on-the-fly help for
individual completion candidates.

> e.g., "Multi-commands" (what does this have to do with
> completion?).  [If these really are unrelated to main purpose,
> why are they part of the same package?]

Call it "multi-completion" if you like (but that term has been used to mean
different things). It is 100% a completion feature: acting on multiple
completion candidates during a single invocation of completion (e.g.
`completing-read').

It _is_ completion; it simply promotes the act of choosing and acting on a
candidate, which until now could occur only at the end of completion, to the
matching and completion phase itself, letting you act on a candidate while
there are still other matching candidates and while you are still able to
change your input and define a different candidate set.

>From the moment that you treat completion as a process of defining a set of
matches followed by an act of picking a match, and you add the possibility
of cycling among or otherwise selecting multiple candidates, the idea of
also acting on those selected candidates springs to mind. Act how? Provide
candidate help. Perform the same action you perform for the final completion
choice. Perform a different action...

Are those all separate features? Are they strictly related logically? I'd
say that they fit well together, and I'd leave it at that. To see that they
fit together, you need either a little imagination and some time spent
reading about them or, better, some time spent trying them out.

Icicles is a big package. I will not convince you of its worth as long as
you don't take a serious look at it and you remain at the "sounds like",
"seems like", "I get the impression", level. The doc presents fairly well
the features and how to use Icicles, and it is trivial to load Icicles and
give it a try. If you honestly want to learn about it and get a feeling for
it, there are no obstacles.