RE: propose adding Icicles to Emacs

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

>     Your approach makes each command definition that uses "!" in
>     the interactive spec deal with the list (collective) and
>     non-list (individual) cases together, in a conditional in its
>     body.
>
> That's the purpose of `!': so you can distinguish those two cases.
> If you don't want to distinguish them, then you don't write `!'.

I understand that. And if you want to distinguish them, then you need the
conditional, as you indicated.

> Then the command gets called once for each argument.

Are you saying that if you use `!' in the interactive spec then a user can
have only the whole-set-at-once behavior and not also the
act-on-each-candidate behavior? I thought we were talking about _adding_ the
former, not substituting it for the latter. Now it sounds as if you want to
take the latter away.

Acting on a set as a whole is different from acting on each of its elements.
There is no reason to try to substitute one for the other, instead of
providing for both.

> I think it is a simple feature that makes it possible to implement,
> in a clean way, all the multi-command features that we have discussed.

I don't know about that. I haven't heard you confirm or explain how it
provides for the actions #1-#4 that I listed (1: help action, 2: main
action, 3: alt action, 4: delete action). You've only mentioned the main
action (#2) and applying a different action to the list as a whole (#5). And
it seems you are saying now that acting on the list (#5) would mean
foregoing acting on all matching candidates individually (`C-!'). It's not
clear to me what you are saying about the various actions.

Another reason I gave for using variables bound to action functions is so
that other code can override or test such a binding. For example, one
multicommand calls another to implement some of its behavior, but it
overrides a default action function or tests whether an action function is
defined. I gave an example illustrating the override.

>     This still assumes your automatic treatment of multicommands via
>     `call-interactively'.
>
> Exactly.  That's a better method.

The "this" was an example that used my approach of binding the
set-as-a-whole action function. It was a hybrid example that adopted
(assumed) your C-language enhancement to support the use of an argument for
a multicommand.

> > I think it is a simple feature that makes it possible to implement,
> in a clean way, all the multi-command features that we have discussed.

Repeating that doesn't show how it is so. You still haven't mentioned how
you will you implement/support the various actions (#1-#6).

> 	The way I do it now separates each of the action functions
>     (the action "implementations", in your terms) from the command
>     definition itself:
>
>     (defun command ()
>       (interactive)
>       (let ((candidate-action-fn 'action-one)
> 	        (all-candidates-action-fn 'action-all))
> 	    (action-one (read-file-name "File: "))))
>
> That's why my method is better.

What's why? What's the reason? If a programmer defines a command with each
of the actions #1-#6, then, IIUC, you end up with a big conditional in the
command body with your approach. Why is that better?

> (Note that this example reads a minibuffer argument inside the body of
> the command, contrary to Emacs convention, which says you should read
> them inside `interactive'.)

Do you mean this convention from the Elisp manual (sans rationale BTW)?

  "In most cases, you should not call minibuffer input functions in the
   middle of a Lisp function.  Instead, do all minibuffer input as part of
   reading the arguments for a command, in the `interactive' specification."

In most cases, OK, but it depends on the context. When input is read inside
`interactive' it is done before other processing by the command (unless some
such processing is also shoved inside `interactive', before the read, which
can result in contrived/unnatural code). That's not always the most
appropriate behavior.

You can also say that one should, in most cases, read command arguments
inside `interactive' (which is not quite the same thing). What is read here
is not an argument (or a "minibuffer argument").

You can argue that it should be, that it's better, in most cases, to read
user input as arguments. But, as you know, without redefining some of the
basic C infrastructure (as you now intend to do), it was not possible to put
the multicommand read inside `interactive'. Thus the departure from
convention. I gave the hybrid example to show that I agree that it would be
good to be able to treat the completion candidate as an argument.

Anyway, as I already said:

> 	I'm not against such an approach. I'm just saying that I'm
>     not yet convinced it is an improvement. Of course, you don't
>     need to convince me.

You don't need to convince me, but I do wonder if/how you intend to support
each of the possible actions we've discussed so far: #1-#6, plus letting
users apply #2 (main action) and #3 (alt action) to all matching candidates
individually.