RE: propose adding Icicles to Emacs

[Drew Adams]

>     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.

Between an earlier email from me and the one you are quoting, I think I
answered that. I don't think I left anything out. I went through the code
bit by bit, explaining what was involved and what would need to be done, if
this redefinition were to dispensed with.

>     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?

No. That hook runs whether completion is used or not. It even runs for
`M-:', for instance. Anyway, I said that you can eliminate this feature.
Let's not belabor this stuff; there's already enough to discuss.

>     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?

They can get into `default-directory' on Windows, at least. IMO, they should
never get into it, but they can.

>     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'.

Right. I don't know if it is still a bug, but I think so. I believe I've
seen other users (of Emacs, not Icicles) complain recently about the
*Completions* window not going away. In fact I'm almost positive it's still
a bug, because when I turn off Icicle mode I notice it.

This happens when you have non-nil `pop-up-frames'. There are several ways
in which Emacs is not very friendly to  non-nil `pop-up-frames', as I've
mentioned before.

FWIW, in my own (non-Icicles) code, I also redirect the focus of
*Completions* to the minibuffer. That is, I give the standalone
*Completions* frame its own display function, and I do this inside that
function:

  (redirect-frame-focus (selected-frame) 1on1-minibuffer-frame)

IMO, that should also be built into Emacs for such a context. The input
focus for *Completions* should always be the minibuffer. Anyway, this is
off-topic...

>     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?

General: you might want to define a command that uses an existing that calls
`completing-read'. You don't therefore have direct access to the call, so
you cannot change the value of the REQUIRE-MATCH argument that was passed.

Specific example: Some users like buffer-name completion to always be
strict, a la Ibuffer, rather than lax, a la `switch-to-buffer'. Icicles has
a user option that you can set to make REQUIRE-MATCH effectively strict for
Icicles commands that use buffer names.

Those buffer commands bind variable `icicle-require-match-flag' to the
user's choice (which is the value of `icicle-buffer-require-match-flag'. My
`completing-read' checks `icicle-require-match-flag' and overrides the
REQUIRE-MATCH arg if appropriate. I mention buffer-name completion because
it is a common example, but the same principle applies to any completion.

>     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.

Please see my reply to one of Stefan's emails on this topic. I am repeating
myself. Anyway...

1. `M-*' (`icicle-narrow-candidates') calls `completing-read' or
`read-file-name' again, recursively, to match an additional pattern you
provide. I call this "progressive completion", and it is akin to piping
greps. In this recursive call, the same value of REQUIRE-MATCH should be
used. Since this is in a different command, I need a global variable for
this value.

2. Also, `icicle-candidate-action', which is `C-RET' (likewise, the
alternative-action command, bound to `C-S-RET'), uses the recorded value of
REQUIRE-MATCH to handle the action. When a match is required, the candidate
must be one of those in `minibuffer-completion-table'. For lax completion,
`C-RET' lets you act on any input you type.

Note: having a global variable for REQUIRE-MATCH just makes sense, to me. We
already have the same thing for PREDICATE and TABLE
(`minibuffer-completion-predicate', `minibuffer-completion-table'). Icicles
uses these variables also for minibuffer commands. There is also a variable
`minibuffer-completion-confirm'. But there is no
`minibuffer-completion-require-match' - that's what my
`icicle-require-match-p' is.

>     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.

Maybe. I don't know. You can get an idea by checking where it is used.