Re: propose adding Icicles to Emacs

[Richard Stallman <rms@gnu.org>]

    I'd propose adding Icicles first as an optional library, without trying to
    integrate any of it deeply with Emacs. Later, we could look into a possible
    tighter integration.

That is a very bad idea.  "Temporary" solutions tend to become
permanent, and to prevent that from occurring requires insistence.  No
software developer should install code meant to be temporary unless it
is essential to do so.  Icicles features are nice, but installing them
is not essential.

Therefore we will put the code into the form we want to keep permanently
and then install it.

    > Why does it do this?

    Because those replacements are enhanced versions. They are typically
    multi-commands that 1) keep the same behavior as the original, as long as
    you don't use any special Icicles minibuffer bindings, but also 2) let you
    take advantage of those minibuffer bindings (e.g. `C-RET') to get the
    multi-command behavior.

Let's suppose I can magically implement multi-command behavior without
the need to define separate multi-commands to do it.  (I think I can,
and I explained how.)

Is there any other reason in icicles to define new commands
to replace the existing ones?

If so, what is it?  Maybe I can find a better way to implement that,
too.

The need to replace commands is a complexity, and the code will
be much better if we avoid that complexity.

    Yes, you must define a new command, in order to adapt a given existing
    command to multi-command use. This is a good thing, as some commands might
    not lend themselves well to multi-command use (i.e. it might make no sense
    for them, adding nothing).

That is no argument against making multi-command behavior magic.
Just respond, "If it isn't useful there, don't use it there."

			       And, more often, it is appropriate for some
    commands to have a slightly different action function for candidates during
    completion than after completion (for instance, because the
    buffer/window/frame context or the use context might be different).

This might be a real issue.  Can you please give an example or two?

    If Icicles does not break anything, and it does not have a lasting effect
    when you leave Icicle mode, then I think how it is implemented should not be
    a concern.

That is true if you distribute it separately.
If it is part of Emacs, that changes everything.
We want Emacs to be modular.  My proposed implememtation
of multi-command behavior is totally modular.  I think we
can make it work with NO changes in any specific command. 

    The macro expansion of a multi-command defined using #1 or #2 is quite
    complex. Some of its definition implements context management (window,
    frame, buffer), and some of it implements treatment of possible errors from
    application of the action function. For example, the original buffer,
    window, or frame, to which we often want to return, might have been deleted
    by application of the action to a particular candidate (e.g. if the action
    is to kill the buffer, and the candidate acted on is the original buffer).
    And we usually want to keep the focus after action application on the
    minibuffer's frame, so that we can possibly keep using `C-RET' etc. on other
    candidates.

The code in call-interactively may need to deal with such cases.  I
think it can do so in ways that are independent of the specific
command that was run.

    Wrt prefix args: C-u is treated specially during completion, so that, for
    instance, you can apply it to individual candidates that you act on using
    `C-RET'. That is, you can use a different prefix argument each time you act
    on a candidate, if you like.

I just assumed it was the other way.  We could handle the prefix this
way just as easily.

     Remember, that, by default, you can act on the
    same candidate multiple times. Sometimes that makes sense, sometimes it does
    not.

Can you give me an example where it does not make sense?

    2. It's appropriate, for many commands, to specialize the action behavior
    during completion. See the commands that explicitly bind
    `icicle-candidate-action-fn', as opposed to just using
    `icicle-define-command'. Command `icicle-search', for instance, could not be
    defined using `icicle-define-command'.

Can you please explain an example of this specialization?
Then I can think about its consequences.