Re: propose adding Icicles to Emacs

[Richard Stallman <rms@gnu.org>]

    You seem bent on automatically converting all commands to multi-commands.
    That might be useful, in a limited way. But programmers will still need to
    be able to define multi-commands that go beyond the simple case. I gave
    `icicle-search' as an example.

Would you please explain what is special about it?

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

    There is no need to replace any commands. Keep them all.

As you have described it, Icicles replaces the command find-file.  It
does this by defining a new command (Icicle-find-file?) and remapping
remapping find-file to that.

I think this complexity is unnecessary, and I want to try to avoid
installing it.

The only purpose that I know of for defining Icicle-find-file is to
implement multi-command behavior.  Is there any other reason?

I have proposed a modular and clean way to provide the multi-command
behavior, without the need to replace commands in this way.  You said
that my proposal doesn't do the whole job.  Maybe you are right, but I
need you to explain.  What part of the job does it not do?

    No one is against modularity. I have not seen a "proposed implementation",
    beyond some vague hand-waving.

I gave you an outline of the scheme.  Of course I don't have all the
details.  I am trying to work out the details but I need your help.

    However, that needs to be done
    carefully and fully. For example, use of a standalone minibuffer and non-nil
    pop-up-frames should also work.

I expect we can write the code in Fcall_interactively to do TRT in
those cases.  The only way to make sure is to try it.

    I agree about "independent of the specific command that was run", but only
    in the case of run-of-the-mill multi-commands.

Even if this only handles the run-of-the-mill multi-commands, and the
exceptions are handled by your macros, that is still a big
simplification.  And we can continue trying to make this mechanism
better; perhaps we can make it handle more of the commands.

    For some multi-commands you
    want the frame focus to end up in a different place when you are done, for
    example.

Could you tell me about one example?  Maybe I can find a simple
general mechanism to handle this too.

    You might typically work in the buffer of application after using a
    multi-command, or you might instead typically want the minibuffer frame to
    continue to have the focus so you can use it again - different commands have
    different use cases.

Can you tell me about one example of each type, so I can see
why this is so?

    I had my multi-command definition macros available for my own use,
    yet I did not use them to define some of the multi-commands. Why?
    Because they are not flexible enough - they cannot be flexible
    enough. There is no substitute for being able to code what is
    needed in a particular case.

Maybe that is true, but first let's make a reasonable effort to make a
general mechanism handle as much of the job as possible.  Eventually
we may decide to handle a few hard cases with your macros.

    Practically every place where I have used a non-nil value for
    `icicle-use-candidates-only-once' is an example. It is not so much that
    multiple invocation would be harmful (though perhaps that can also be true
    for some commands). It is that, in many cases, it is handy for the user to
    remove the candidate from the list of available candidates, once it has been
    acted on.

We could build that into the low-level mechanism too.  It would be
quite clean.  Fcall_interactively just has to bind a certain variable
to nil, which holds a list of completion alternatives to exclude.
display-completion-list will ignore the alternatives in this list.
Then, each time around Fcall_interactively adds the proper argument
value to this list.

We could control the feature with a character in the interactive spec,
as in

    (interactive "#bDelete Windows of buffer:")

where # specifies using candidates only once.

    FYI - wrt clicking the `delete' key to remove a candidate - I've recently
    defined a complementary feature, to save a candidate for later
    consideration. I haven't yet uploaded this feature to the wiki, but I'll do
    so soon, after testing things a bit more.

These features seem interesting.  I think they can all be implemented
cleanly in Fcall_interactively, but this suggests we might want to make
it call some Lisp code which would handle some of these cases.

    It's best to read about what Icicles search offers and how it works, and
    then look at the code for `icicle-search' as an example. I'll be glad to
    answer questions, but I don't want to repeat here what is already written
    elsewhere. Please see the links above.

I will be glad to read the text you've already written, but finding
that text would be a pain for me.  Could you please email it to me?