RE: propose adding Icicles to Emacs

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

> >> Also there is another bug (I can't believe it's by design):
> >> after typing <C-next> the face description in the *Help* window
> >> goes out of sync with the face name highlighted in the
> >> *Completions* window and displayed in the minibuffer (e.g.
> >> when the current selected completion is `bold-italic',
> >> the *Help* window displays the description of the previous
> >> face `bold').
> >
> > No, this is the normal behavior of `C-next'. When you hit
> > `C-next', it acts on the _current_ completion candidate and
> > _then_ moves to the next one (so you can then act on it, in
> > turn). `C-next' is thus a shortcut for `C-RET'
> > (act on the current candidate) followed by `next' (make the
> > next candidate current).
>
> When I type `C-next' I expect it acting on the _next_ completion candidate
> (`next' + `C-RET').  When I want it acting on the _current_
> completion candidate, I can simply type `C-RET'.

Well, what can I say? That's what you expect and that's not what you get. We
disagree. Like I said, I first implemented it the way you think you would
prefer it, I corrected that design a long time afterward, and even though I
was already used to the previous behavior I preferred the new behavior - and
I still do.

> It is a pity that you changed your original design.  Displaying the result
> of action applied to the previous completion candidate with the name of
> the next completion candidate highlighted in the *Completions* window is
> as confusing as for instance if you typed `next-error' and see
> the previous match in the source buffer with the next match highlighted
> in the grep/compilation buffer.

This is not `next-error'.

The current candidate for action (including help display) is not only
highlighted in *Completions* but also inserted in the minibuffer so that you
can edit it or accept it as is. That is, you hit RET or C-RET to act on the
current candidate, which is in the minibuffer.

What should be in the minibuffer after you do that? My answer: the next
available candidate, so that you can act on it, in turn (whether with
`C-RET', `RET', or `C-next'). You should not see, in the minibuffer or
highlighted in *Completions*, the candidate that you already acted on. The
minibuffer input after you act on a candidate has to be a different
candidate, if you are to be able to act on successive candidates. What you
see in the minibuffer should again, per standard Emacs behavior, be what
will be acted on if you hit RET (or C-RET).

This, however, does not dictate what `C-next' should do. I say it should
perform the defined action on the current candidate and then prepare the
next candidate for possible action. You say that it should do nothing to the
current candidate and should act directly on the next candidate. It could be
designed either way.

For me, the text that appears in the minibuffer as input should be the
target of any user action. For you, `C-next' should perform an action on
text that is not yet in the minibuffer, and it should show that text in the
minibuffer after the action. With my approach, `C-next' followed by `C-RET'
or `RET' acts on two successive candidates. For you, it acts twice on the
same candidate. Likewise, for `C-prior'. But either approach can be
supported.

With the behavior you propose, a user thinks of `C-next' as not acting on
the current candidate but as acting on the next candidate. OK. I prefer to
think of all actions, `C-RET', `C-next', `C-prior', `C-up', `C-down', as
acting on the same, current candidate. I think this simplifies the user's
mental model a bit. It simplifies thinking about actions, just as it
simplifies talking about them (e.g. doc).

But I can't argue that the behavior you want doesn't also correspond to a
coherent user model.

It is logical to expect to see the result of acting on a candidate only
after choosing that candidate. For me, the candidate that is ripe for
choosing with the keyboard is the one that is (a) highlighted in
*Completions* and (b) present in the minibuffer as your default input.
Choosing it acts on it, and you then see the result.

You would respond that you don't disagree with most of that (display the
result after choosing what to act on), but you think it is logical to
sometimes choose (act on) a candidate that is not the one in the minibuffer.

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.

Anyway, we can go 'round the barn multiple times about this, without really
getting anywhere. I think it's time to agree to disagree. If you as an
Icicles user want to define your own command and bind it in place of
`icicle-next-apropos-candidate-action' to `C-next', it is trivial to do so.
Here is the complete definition:

(defun icicle-next-apropos-candidate-action (&optional nth)
  "`icicle-candidate-action', then `icicle-next-apropos-candidate'.
Optional argument NTH is as for `icicle-next-apropos-candidate'."
  (interactive)
  (when (interactive-p) (icicle-barf-if-outside-minibuffer))
  (icicle-successive-action #'icicle-next-apropos-candidate
                            #'icicle-candidate-action
                            nth))

So your definition would be this:

(defun JURI-next-apropos-candidate-action (&optional nth)
  "`icicle-next-apropos-candidate', then `icicle-candidate-action'.
Optional argument NTH is as for `icicle-next-apropos-candidate'."
  (interactive)
  (when (interactive-p) (icicle-barf-if-outside-minibuffer))
  (icicle-successive-action #'icicle-candidate-action
                            #'icicle-next-apropos-candidate
                            nth))

I have nothing fundamentally against such an approach; I just don't agree
that it is generally preferable. What we can do is ask people to try the
current approach for a while, and then revisit the question after that
trial. It is trivial to flip the behavior if we decide to change it.

I think I mentioned that I in fact employ the approach you prefer for the
particular case of `icicle-search', because the use case is somewhat
different. The *Help* display is a bit similar to search, so I cannot say
that you are 100% wrong about it: if help display were all that `C-next' is
about, you might convince me. But help is available all of the time, as a
secondary action, when the primary action is something else. And for that
primary action, at least, I think it is clearer if the user's simple mental
model of "do something to act on the current candidate" is reinforced by
`C-next', so that a user can think of `C-next' as an atomic action on the
current candidate, just as for `C-RET' and `RET'.