RE: propose adding Icicles to Emacs

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

> When I browse completion candidates using <C-next> and <C-prev>, I look
> not at their names in the minibuffer or in *Completions* window, but at
> the output window of the action performed on them (displaying help for
> a function/variable/face, or a file).

It depends on the action, doesn't it? In the case of browsing help, you are
right about eye focus, but only if you ask for help on each candidate in
succession. Even for help browsing, it is often the case that you do not
check the help of every candidate in the matching set. Rather, you check
candidates of interest, which might involve a sequence of several in a row
(`C-M-next') but which also might involve skipping some that you are not
interested in. You might use `next' to skip those, or just use `C-M-mouse-2'
to ask for help on specific candidates you click.

So, even in the case of help display, I don't agree that one's attention
when browsing is always on the *Help* buffer instead of *Completions*. It
all depends how you use it. Yes, if you just cycle through everything with
`C-M-next', without checking *Completions* to see what you want help on,
then your eye remains fixed on *Help*.

> The mismatch between the window
> that displays the result of action on the completion candidate (which
> often contains the name of the completion candidate)

Again, it depends on what the action is. You are focalizing on help
browsing, and, yes, the candidate name appears in *Help*. That is not
generally the case.

> and the name of the
> completion candidate highlighted in the *Completions* window and in the
> minibuffer is not only confusing but also *dangerous*.  It might lead to
> deleting (with S-DEL) a wrong item (including a wrong file).  I don't want
> to lose a file through misleading UI.

Yes, there is some risk associated with `S-delete' (not `S-DEL', BTW), and
with `C-!' (act on all candidates) also. This is the case regardless of the
behavior of `C-next', but I do see your point about eye-focus on *Help*
followed by `S-delete'. Perhaps `S-delete' and `C-!' should be disabled by
default (a la novice bindings), or perhaps you should need to confirm their
application. I don't have a strong opinion about that.

I've heard your preference and reasoning. I've agreed that I too felt, at
first, that what you prefer was appropriate (I started by adding only help -
no actions, so I too was focalized on help at the time). So far, no other
Icicles user has expressed a similar preference, however. (And no one has
complained about the risk of `S-delete'.) But I'll be the first to say that
lack of user complaint does not prove user acceptance or good design.

I proposed that people experiment with the current bindings, and then we can
discuss it. I'm open on this question, but I won't change it based only on
your preference after only a little use. We could also consider having a
user option for this, if opinions end up being evenly divided. So far, we
have only two voices, and you have played with it for only a short time, and
perhaps mainly with the candidate help. For now, you can easily flip the
behavior to get what you want (using the code I sent). Experiment with that
for a while to see if you prefer it in all contexts.

Again, the main reason I prefer the current behavior is so that the target
of the next action, whatever it might be, is the candidate that is
highlighted, which is also the candidate in the minibuffer. This makes it
_easy to see what you will act on_, which is, as you point out, especially
important if you use `S-delete' to delete the object associated with the
current candidate.

Also, I'm speaking only for Icicles and my Icicles development. Richard has
something else in mind for vanilla Emacs, IIUC. Who knows what Icicles
features he will want to add or adapt for Emacs, or what his choices for
this kind of cycling behavior will be?

> > I cannot convince you, but I'd suggest that you not focalize only on
> > candidate help, where the action is displaying help on the current
> > candidate. "Act on" can mean anything, depending on the
> > context, and I think in most contexts the current behavior is
preferable.
>
> You could try to separate displaying help and performing other actions
> to different keys.

Help is already on different keys: `C-M-next', `C-down', `C-M-RET' and
`C-M-mouse-2' for help. For actions, there is no Meta: just `C-next', etc.

It is true that I also let the non-Meta bindings default to help display
when there is no specific action defined for a given command. That's a
convenience, but it could be removed if it leads to confusion. The doc does
not teach you (I hope) to get in the habit of using `C-next' to obtain help.
If it does, then I need to fix that.

To be clear, there are three sets of bindings, for three possible actions on
the current completion candidate (which is highlighted):

1. Main action: `C-RET', `C-mouse-2', `C-next', `C-down'

2. Alternative action: `C-S-RET', `C-S-mouse-2', `C-S-next', `C-S-down'

3. Help action (help on candidate): `C-M-RET', `C-M-mouse-2', `C-M-next',
`C-M-down'

There is also the standard action of final choice (`RET', `mouse-2') and the
operation of cycling without acting (`next', `down'). There is a single
binding for the object deletion action: `S-delete'. There are also bindings
for removing the current candidate from the list, `delete' and `S-mouse-2',
and for saving it for later action, `insert'.