bug#4718: 23.1; C-h f gives doc for the wrong function

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

> > Letting RET complete using prefix completion is not 
> > problematic in the way that letting it do so with
> > partial completion is. With only prefix completion, `dolis
> > RET' can only complete to something that has `dolis' as a 
> > prefix. When there is only one such completion, it is not
> > very hard to guess what that is.
> 
> But there's not necessarily just one completion.

I said, "When there is only one such completion."
That's the case in question in this bug report.

There is little problem when there are multiple completions - you see them, even
for partial-completion.

There is far less confusion with prefix completion, but there is no great
problem even for partial-completion when there are multiple completions.

For prefix completion, all of the completions have the same longest common
prefix, which is what you see. Especially with longer input, the guess wrt the
completions is a narrow gap; it is nothing like the case for partial completion,
where the possible completions are all over the map.

But even for partial completion, there is little problem when there are multiple
completions. You can see them, even if you hit RET.

The problem is when there is only one completion and you hit RET. For prefix
completion, you can pretty much guess what the completion is, especially for
long input. For partial completion you have no idea.

> > That means both (a) it is unlikely that the sole completion 
> > would be much longer and therefore hard to guess and (b)
> > it is not unreasonable for both the program and
> > the user to consider the input as pretty much the whole 
> > function name.
> 
> It is not unreasonable, of course. But neither it is unreasonable the
> opposite: to understand RET as, "if there's only one completion, give
> me that". I think it's useful.

But you don't know what that one completion is. That is the problem. You haven't
got a clue. So when you say "give me that one", you don't know what one it is
that you're committing to.

With prefix completion, there is really no comparison wrt the amount of
knowledge you have about what you're accepting - you generally know what you
will get.

So yes, RET's completing behavior can be useful - with prefix completion. With a
mix of completion styles, however, it's like playing darts in the dark.

It is precisely the fact that it is useful with prefix completion that I do not
want to see us simply institute a confirmation policy for RET in a blanket way.

That is why I suggested that RET confirmation is called for only when the sole
completion does not have the user's text as a prefix. IOW, only for the
"surprising" partial-completion case. And again, the problem I'm reporting is
particularly wrt a sole completion.

> > That's one solution I see: not ask for confirmation except 
> > when the completion does not have the input as a prefix.
> 
> That seems reasonable, though surely there's people who will feel as
> strongly about it as you feel about the current default behavior :-)

Well, there are always people who feel differently about everything in Emacs. We
have options when there are important differences in approach for users.

By default at least, Emacs users should not have to guess what's happening or
feel inadequate and at a loss because they don't understand what's going on -
why they get the results they get. Users should feel like they control Emacs.
They shouldn't be uncomfortably surprised or wondering WTF.

The new completion behavior is a WTF? behavior in many respects. The default
behavior should be tamed to be less surprising. Anyone who comes to feel
comfortable with getting an unknown, or who particularly likes playing darts in
the dark, can choose another value for the option that would control this.