RE: propose adding Icicles to Emacs

[Drew Adams]

>     I think it would be good to include Icicles in Emacs.
>     Clearly, we wouldn't want to enable it by default since it changes the
>     behavior too much for many people's tastes, but just like
>     iswitchb and ido I think it's a valuable extension.
>
> It sounds like Icicles contains many good features that should be
> installed. Perhaps all of them.  But we should not keep them as a
> bundle simply because they are offered to us as a bundle.  We
> should separate them if they make more sense separately, and keep
> them unified if they make more sense unified.

Fine as a generalization. I don't disagree with the logic, including the
"simply because", "if", and "if". Where do we go from here?

Let me be clear about my position. I see two possibilities, A and B. I
prefer A, but I can also live with B.

Plan A -

My suggestion is to proceed in two stages: 1) take Icicles (i.e. add it to
Emacs) as a bundle now, offering it to general Emacs users as a separate,
optional package with its current functionality and design, and 2) later,
examine parts of Icicles that might usefully be peeled off and added to
vanilla Emacs itself, starting with the low-hanging fruit that doesn't shake
the entire tree (either Emacs or Icicles).

There is no reason that Icicles and Emacs cannot live together as each is
now, even if there might be some potential to make each even better by some
careful simplification, merging, or whatever in the future.

For stage #1, the immediate process of package addition and the period of
cohabitation that I propose, I am willing to do some minor cleanup, _if_ it
is clear to me what is required and _if_ it doesn't jeopardize the correct
functioning of Icicles. I'll consider such changes on a case by case basis,
and only _if_ someone works with me to make clear what is needed. I strongly
suggest that we make only minimal changes that are truly needed to added
Icicles as a separate package (stage #1).

Plan B -

An alternative (to my two-stage proposal, plan A), which I do not prefer but
which could also be workable for me, is for you not to add Icicles to Emacs,
but to instead take some of its ideas and add them in your own manner to
Emacs. That too works for me. In that case, I'll keep Icicles, and you can
borrow ideas from it if you like. That way, you will be clear and content
about what you get and how you implement it, and I won't have the discomfort
about not understanding what you want changed, or the risk of breaking
something because you've asked for changes that are not sufficiently thought
out. I will of course be available to answer questions about the existing
Icicles features and their implementation. And you can take pieces of
existing Icicles code, if you like. _You_ can take - I won't be chopping up
Icicles in this scenario.

I would prefer plan A - to let general Emacs users take advantage now of all
of Icicles, as they do Ido and Iswitchb, to experiment with it, provide
feedback on how its parts fit well together or don't, etc. But if you prefer
plan B, to treat Icicles only as a quarry of ideas, taking some ideas here
and there or not, that's OK by me too. I will continue to develop Icicles
separately, and if a piece of it ultimately becomes superfluous because
Emacs has implemented something similar, I can then remove it from Icicles.
Plan B admittedly has the advantage of going beyond the throw-away
prototype, doing things better the second time around.

If you choose plan B, I would ask only that you try to proceed in a way that
will not make it difficult for people to use Icicles with Emacs in the
meantime. For example, if you start adding a different kind of multi-command
functionality, please do so in a way that won't conflict too much with using
Icicles. That might not be easy or obvious, but if we work together and stay
mutually informed, things could be worked out. I'm not demanding that you
don't break anything for Icicles - I'm only asking for consideration and
cooperation. For now, Emacs does not do much with the minibuffer and Icicles
does a lot. Icicles uses lots of new minibuffer bindings, for instance. If
Emacs starts using lots of minibuffer bindings that conflict, then let's
agree to try to work something out.

I'm offering Emacs the ideas of Icicles - and the design and implementation
too, if you want it. I hope you can offer cooperation in return. I'd like to
see, in order of preference: either (plan A) Icicles working inside Emacs or
(plan B) Icicles working outside Emacs (in the sense that it is now
"outside"). I don't want to see Icicles no longer working anywhere because
it has been dismembered beyond use within Emacs or because Emacs has built
up its own features that prevent it from working.

> At least one should be implemented differently: multi-commands.
> I explained how it is possible to simplify this tremendously
> if you don't insist on doing the work at the Lisp level.

You explained no such thing. You asked "how does it know what to call?", "is
it the same command?", etc. You asked if every command couldn't be
automatically converted to a multi-command. I responded to all of this in
detail - you have not replied to any of that. You rather cavalierly proposed
a different implementation of a feature whose description you were not yet
clear about and were therefore still asking about. I explained more about
the feature, and I asked you for more detail about your vague redesign - no
reply.

I explained that I don't want to redesign or to reimplement the basic
design. I said that if others wish to do that, later (phase #2 of plan A),
then that's another matter. I recommend plan A: leaving the basic design and
implementation as they are now, adding the package now, possibly with some
minor modifications to fit standards or preferences, and then, perhaps,
revisiting design and implementation questions bit by bit later.

Once Icicles has been added to Emacs (plan A), IIUC, there are two
possibilities: (1) I continue to maintain it for Emacs (within Emacs), or
(2) someone else does that. I would prefer to maintain it myself, as I
intend to do so anyway, for my own version.

However, if Emacs developers want to rework the code extensibly, then that
is possible - after Icicles belongs to FSF, and at that point my
participation in the maintenance might diminish or dry up altogether. I have
nothing against performing some of the functionality in C, for instance, but
I will not work on that C code myself (you will be glad of that!). Once you
own it, you can break it as you like (to twist the Pottery Barn aphorism a
bit).

If someone wants to seriously take a look at reworking parts of the package,
I'm willing to spend some time working with that person or persons. But I
will not take some vague directive to go off and redo things, and then come
back to you hoping that things might have been understood and reworked to
your satisfaction. I don't read minds, among other things. In sum, either
you do it or I do it, and if I do it then I need to understand precisely
what "it" is, and I want to agree that "it" really should be done.

I am not saying "take it as is or leave it". I'm proposing a couple of
different ways you can take it. I'm saying that if there are changes you
think should be made, then let's discuss them _in detail_ first. And I'm
strongly recommending not to touch the basic structure of the code - at
least not for a while. Let users use it as it was intended, and let its
evolution and improvement be gradual, informed, and _deliberate_.

> I don't know all the features in Icicles.  Perhaps other such
> simplifications are possible, or perhaps not.  Someone needs to check.

Someone needs to take it seriously, one way or the other. Not knowing all of
the features is OK at this point, but it is not OK to redesign without
knowing all of the features and how they work together. (But you have the
option of plan B.)

I'll consider concrete suggestions of any nature, but I will be reluctant to
slash willy nilly and reconstruct. I've said it before; it should be quite
clear now. It won't happen on my watch, and without me understanding what it
is.