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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> But we should not impose a regimental `ask' for this in general.
> The problem does not exist for prefix completion.  We should show you
> the sole completion and ask for confirmation only when it does not
> correspond to prefix completion.  Non-basic completion is the only
> case where there is really an element of surprise, confusion, and lack
> of understanding.

I disagree, the same problem exists for prefix completion.  Maybe it's
less frequent, but it exists nevertheless.  Which brings us to the
reason why we don't currently ask: choosing the wrong name is harmless
because C-h f does not perform any dangerous operation that might lose
you some work.

>> For what it's worth I have a local patch that indirectly changes this
>> behavior: it accepts any function name (even non-existing ones),
>> requires confirmation for non-existing ones, and then tries to guess
>> which file to load to find the function.

> The problem is not non-existing functions.  In that case, the current
> code would still say `No match'.  The problem is (a) treating
> additional patterns as matches when combined with (b) RET.

Reread what I wrote: I said "indirectly".
It's related not for its functionality but because if we want to be able
to accept non-existing functions, then RET can't perform completion
any more.

> I don't even think this is specific to `C-h f'.  We should probably do
> the same thing most of the time: make RET confirm when the completion
> is not an obvious one (i.e. a suffix).

That's almost already the case: it's fairly rare for Emacs completion to
use this kind of strong `require-match'.


        Stefan