RE: propose adding Icicles to Emacs

[Drew Adams]

>     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,
>
> I have explained already why this is a bad idea.
> It is not an option, because it adds a lot of unmodular code.

Are you sure that that code cannot be made modular enough to be added,
without breaking the basic design and starting over from scratch? Have you
actually looked at the code? I'm not suggesting you haven't; I'm just
curious whether your idea of how unmodular it is comes only from reading
email or from actually looking at the code.

> Icicles was implemented as an add-on, and to work with no changes
> at the C level.  The right way to implement the features in Emacs
> is different.

Can't argue against that generality.

>     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.
>
> In effect, you have declined to help with installing these features in
> the right way.  I'm disappointed, but we can't make you do it.
>
> We'll just have to see whether other people decide to do it.

Please read what you just quoted, and then read what you wrote just after
it.

What you quoted is a restatement of what I understand to be your position
now: you don't want to add Icicles to Emacs, but, instead, you want to "take
some of its ideas and add them in your own manner to Emacs". Or, in your own
words, "The right way to implement the features in Emacs is different." So,
if you interpret my phrasing of that as non-cooperation, then you should
also interpret your own phrasing of it in the same way. We are, I believe,
saying the same thing.

Why are you trying to twist what I wrote into a statement of refusal to
cooperate or participate? That guilt trip is unjustified, and it doesn't
work with me. "Take some of its ideas and add them in your own manner" is
_exactly_ what you propose, no? Where is the non-cooperation on my part in
that statement?

I think we are talking about the same proposal, which I called plan B:
abandoning the design of Icicles, since it was made as an add-on, and
starting over to implement the features in Emacs differently. I've said that
that works OK for me, though I prefer plan A. I repeat: I'm OK with plan B.

In fact, I agree that, if done right, the result of plan B could be better.
Icicles is a prototype, if you like, and there is nothing wrong with tossing
it and making a fresh start, keeping some of the ideas in mind. (However, as
I said, as long as Emacs does not offer equivalent functionality, I'll also
continue to offer Icicles separately as an add-on.)

> There is another option: start with Icicles, rework it until its
> implementation is clean and modular, and install that.  For some of
> the features, this may be easier.  It too will wait for volunteers,
> though.

It will at least wait for a clear picture of what is meant by that. "Go out
and make it modular" is not helpful to me.

I offered (plan B) my ideas or (plan A) my ideas plus my design and
implementation. I said I preferred plan A, but plan B is OK too.

Plan A: Recognizing that there is a lot of code and that there is some risk
of breaking things when modifying it, I stated that it is better for plan A
to be done in two stages, the second of which can tightly integrate Icicles
features with Emacs, and the first of which would stay closer to the current
design, to proceed conservatively. Stage 1 would be more or less my existing
design; stage 2 would be whatever you want. In stage 1, Icicles would be
sure to work well, and would remain encapsulated, as it is now. In stage 2,
Icicles could be dismembered and abandoned, possibly with some parts moved
inside Emacs.

Obviously, Icicles is an add-on now. I did not try to modify standard Emacs
source files. Recognizing that moving Icicles to Emacs in any way would mean
removing some of the add-on aspects and doing things directly in the source
code, I offered, for plan A, to clean up my implementation to some extent
(keeping the basic design): "_if_ it is clear to me what is required and
_if_ it doesn't jeopardize the correct functioning of Icicles...
consider[ing] such changes on a case by case basis, and only _if_ someone
works with me to make clear what is needed."

It should be clear from my emphasis here that: (1) I am offering to clean up
the code, (2) I am reluctant to dismember everything at once, for fear of
breaking things, and (3) I don't want to receive only some nebulous
direction "all you have to do is..." - I want to know exactly what changes
are requested, and I want to understand those proposed changes. That's
important for plan A, where it is mainly I who would be doing the cleanup
and it is my design that must be kept working after the cleanup. Do not tell
me simply, "Clean it up, bring it back, and I'll let you know if it's clean
enough." For the plan-A cleanup to work, I need to know what changes need to
be made.

Plan B: If the design and implementation are to be completely different,
however, then my _existing_ contribution is reduced to some of my ideas
which you might want to choose - plan B. That too works for me. I said I
would be available for questions and discussion, but if you choose to
redesign and re-implement, then you don't need my existing design or
implementation. I have not said that I won't help in any way beyond
discussion.

What I did say was that in that case (plan B), you are the one deciding what
is to be done and how. You are then in charge of dismembering, designing and
implementing - it is your responsibility. In that scenario, there is no
special need for me beyond consultation - others are probably better
implementors, in any case. However, if you have specific requests for design
or code on my part, then we can see how that goes.

Just as in plan A, I have the concern that any directions from you be
specific and understandable. I have not gotten a good impression in that
regard so far, frankly. I've tried to point to specific code and details, to
discuss how the implementation could be cleaned up for integration, and the
response was cloudy talk of magic solutions, vague mention that you know how
things can be done in a better way. Nothing wrong with your having the
answers in your head, but I don't read minds well, so if you want help from
me for your plan then you will need to find a way to better communicate your
idea.

It's not complicated, I think. There may be many possible ways to proceed,
but I see two main alternative directions: (1) you have your own idea and
are not very interested in the details of what the features are now, how
they work together, and how they are implemented, in which case you are
directing a new construction site from scratch, or (2) you would like to use
my ideas of the features and design, and work with me to get them added to
Emacs. Possibly with some modification - I'm not rigid; my concerns are (a)
not breaking or losing things horribly, and (b) knowing clearly what it is
that you are requesting.

In the first case (1), you don't especially need me or my implementation of
Icicles; you just need bodies (and perhaps some clarification from me of my
ideas). In the second case (2), we need to find a way to adapt the existing
design and implementation, where need be, for the best integration possible
without breaking things.

However, let me be clear that for #1, which is plan B, I remain interested
in Emacs, as always, and I would look forward to discussing how to design
and implement these features, if that participation is welcome. I am
interested in both Emacs and (obviously) ideas related to those that are
used in Icicles. If, in your new construction, you want to know more about
what exists in Icicles, or if you want to know my thoughts about your plans
and implementation, or if you want to know any new, related ideas I might
have, I'll be happy to participate. I am not dropping out in plan B. I am
saying only that it is your construction site.

Now, I would like very much to get back to discussing the _particulars_ of
what might be done, regardless of the approach you choose. Show me, for
instance, what you intend to do for the magic multi-command code, and let's
get back to talking about the details of what works and what doesn't.

>     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.
>
> That may have been true at the time you wrote it.  It takes a long time
> for me to answer mail.  My response to that message went out in the same
> transfer in which your premature rebuke came in.

See my reply to your later mail. As I said there, I still don't see an
explanation of your "magic" in your later mail. Your description of what you
intend is too vague for me to understand it.