Re: propose adding Icicles to Emacs

[Richard Stallman]

    If code is specific to one function only, and you put it on the setup hook,
    then it will also be executed for other functions for which it might not be
    appropriate. Even in cases where that doesn't cause immediate harm, it
    doesn't seem like a clean way to proceed, IMO.

I understand this general point.  But I can only solve problems in
specific.  I'm asking about what you specifically need to do to make
completing-read do what you want.

    1. The treatment of the prompt in my `completing-read' and `read-file-name'
    can be eliminated. It simply adds a reminder to the prompt about some basic
    Icicles bindings. If Icicles is part of Emacs, that will become sufficiently
    known by the doc etc.

Right.

    2. The treatment of `icicle-init-value-flag' can be eliminated, along with
    that option. It does not jibe with the Emacs policy of deprecating the
    INIT-VALUE argument. I like it, but Emacs developers will no doubt rule it
    out. Alternatively, perhaps you could consider adding such an option, to
    allow those users who, like me, would like the default value to always be
    inserted as an init value. In any case, Icicles is not dependent on this.

Can't you use `minibuffer-setup-hook' to do that?

    3. The call to `icicle-fix-default-directory' (in my `read-file-name') can
    be eliminated, along with that function, if this fix is moved into the Emacs
    C code somewhere. This is a hack to convert any backslashes in
    `default-directory' to slashes. Icicles needs it because Icicles lets you
    use backslashes for regexp syntax during completion.

I semi-understand that, but how do the backslashes get into
`default-directory'?  If they serve to control completion, they should
always be eliminated by the time `read-file-name' returns, right?

    4. My `completing-read' also removes the *Completions* window, at the end.
    This was added because the window was not being removed when REQUIRE-MATCH
    is non-nil.

That is a bug.  If it still exists, we should fix it in `completing-read'.

    1. The treatment of `icicle-require-match-flag' can be discussed. I already
    spoke about this. This variable lets code that calls completion functions
    such as `completing-read' override the REQUIRE-MATCH argument. Code can bind
    this so that any contained calls for completion will respect the binding. I
    think this is a good addition and such a variable should be available, but
    others might disagree.

I don't know enough to have an opinion.  Can you present a use case
for this feature?

    I already mentioned the need for a global variable that records (holds) the
    value of the passed REQUIRE-MATCH argument. Perhaps these two variables can
    be combined. The need for the latter variable, for Icicles, is, as I said,
    to be able to call for another completion with the same argument.

I don't understand those words.

    Multi-completions let you provide several strings for each completion
    candidate when you call a completion function. That is, a candidate can be a
    list of strings. The strings are joined using a user-defined join string and
    terminated with a user-defined end string.

If this is useful, the right place to add it is inside
`try-completion' and other functions at the same level.