RE: propose adding Icicles to Emacs

["Drew Adams" <drew.adams@oracle.com>]

>     C-! already applies the action function to EACH of the candidates that
>     currently match the minibuffer contents, one by one.
>
> It sounds like that is the same feature.  That is good.
>
>     In the case of `customize-face', that opens a separate
>     Customize buffer for each chosen face.
>
> I think `customize-face' as a multi-command should put all the faces
> in one Custom buffer.  (Likewise the other `customize-...' commands.)

Then it needs to be defined that way.

The point is that `C-!' simply applies the action function (i.e. what
`C-RET' does) to each candidate, in turn. If that action function is the
current `customize-face', then it opens a new Customize buffer - for that
candidate. Opening a new Customize buffer is part of the current definition
of `customize-face'.

If the same function is used to act on a single candidate and to act on all
matching candidates, then you can get into trouble. The candidate action
function takes a candidate and does something with it. You are talking about
a function that takes a list of candidates and does something with that
list. That is not the same function.

If a given action function had an arg list such as (&rest candidates), then
you might be able to apply it to both a single candidate and multiple
candidates. But in the general case, you don't have control over what the
supplied action function is.

You can try to build in such a treatment, if you forego the ability of a
programmer to specify a different action function. If you try to
automatically convert each command that takes a candidate as arg into a
multicommand that operates on a list of such args, then you can do what you
hint (IIUYC). But you still need to provide the ability to do both: act on
all matching candidates individually (what C-! does) and act on all matching
candidates together. You still need to let the user do either of those. IMO,
it would be best to let the programmer define those actions separately,
instead of coupling them in some automatic way.

IMO, the way to handle this is what I said in my previous mail: bind a
function that expects and treats a list of candidates -
`icicle-all-candidates-action-fn'. That function can do whatever it wants.
In the case of `customize-face', it would open a single buffer for all
matching candidates, whereas `icicle-candidate-action-fn' opens a buffer for
its single candidate.

Opening a buffer is obviously only one possibility of a difference between a
desired action on the set as a whole and the set of desired actions on each
of the set members. The point is that if a programmer wants such a
difference in behavior in a particular case, then s?he needs to specify it
(unless you prohibit that expression and you impose a predefined relation).
A good way to specify those two different behaviors is by providing two
different functions.

Anyway, it's almost impossible to discuss this, because you are not specific
about your approach. We are waving at each other over a great distance,
making inordinate efforts to guess what the other is signaling. If you don't
want to talk about the details of the Icicles design and implementation,
then you need to provide the details of the design and implementation that
you have in mind. Otherwise, this discussion is too abstract to be useful -
we cannot follow each other and contribute anything meaningful.