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

[Drew Adams]

> > 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.

As I said a couple of times, this difference in degree leads to a qualitative
difference. It's not much of a problem for prefix completion, in practice - for
the reasons I gave.

> 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.

No one claimed that it will start a thermonuclear explosion.

The point is that we make it harder, not easier, for users currently. A user now
has to really pay attention and double-check the name of the function at the top
of *Help*. This is error-prone and a time-waster for users. That extra burden on
users isn't necessary.

Does that really happen? Well, I reported it just as it happened to me. It took
me a while in fact to realize that I was studying the doc (args etc.) for the
wrong function - one that is similarly named.

And Juanma was of course right that that happened to me in this case because I
had loaded dired.el but not dired-aux.el (normally, I load them both from the
get-go). It's a good example of what can happen and how Emacs now throws
obstacles our way instead of making things easier.

My expectation was that I was providing the complete name of an existing
function. In Emacs 22, Emacs would have told me there was no such function, and
I would have immediately realized that I had not loaded dired-aux.el. In Emacs
23, Emacs silently substituted another function, and I wasted time studying the
wrong thing.

Will this problem cause a nuclear meltdown? Probably not.

> >> 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'm not arguing that RET should not perform completion anymore. In fact, I
stated that it should. What I proposed is that it not silently accept a
completion, without confirmation, unless it has the user's text as a prefix
(modulo directory, $, etc., as I said).

IOW, for prefix completion RET's behavior is not a problem, in practice. Let's
solve the real problem, and not generalize to "fix" something that isn't broken.

The problem is RET substituting a completion that you would never have guessed
and then accepting that, without ever showing it to you. It is only in such
cases that it would be good for RET to stop, show you what it is about to
accept, and let you confirm or cancel.

Can we recognize such cases? Maybe not in fine-tuned way, never erring one way
or the other. But simply deciding that prefix completion is OK for RET to do
what it's always done, and any other completion is a priori not OK, would help a
lot.

Even in the case of non-prefix completion, we could test if the particular
completion did in fact have the user text as a prefix (meaning that the result
was a prefix completion, even if the method used was not basic completion), and
if so treat it as prefix completion (no confirmation in a case such as C-h f).