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

[Drew Adams]

> > emacs -Q
> > C-h f dired-byte-compile RET
> 
>   M-x load-library <RET> dired <RET>
>   C-h f dired-byte <TAB> => dired-do-byte-compile <RET>
>   => description for `dired-do-byte-compile', as expected.

I didn't hit TAB.  I hit RET:

M-x load-library RET dired RET
C-h f dired-byte-compile RET
=> description for `dired-do-byte-compile', NOT as expected.

I entered one entire function name. Emacs didn't complain that there was no such
function. Emacs instead silently gave me the doc for a different function.
That's totally inappropriate.

When I hit RET, Emacs should say `No match' and not accept my erroneous input,
as it used to do in Emacs 22 and before. If there is no function whose name is
`dired-byte-compile', then when I try to enter that name Emacs should tell me
that immediately: no such function.

In no case should Emacs go off and come back with the doc for some other
function - and without even showing me that other function's name first! That's
ridiculous. That is not user-friendly at all.

Imagine if you paste a complete URL in your browser and you get a totally
different Web site from what you request, the browser thinking that it is being
helpful because it notices some similarity between your URL and another that it
knew about.

Can you imagine your Web experience in that case? Imagine if your browser does
that each time you click a broken link: "helpfully" transforming the bad URL
into a different one that "works" - but that corresponds to an unrelated Web
site.

The idea is not to maximize your chances of getting to some Web site, any old
Web site. What you want is to be told that the URL is bad: `No such site'.

Entering a complete URL is very different from (1) typing part of a URL, (2)
asking the browser to help you find a relevant complete URL, and then (3)
hitting RET to show your agreement with its proposal.

It's also different if your browser first tells you that a complete URL you
entered is bad and then asks if you want it to try to guess another URL. In that
case (a) you are told there is no match and (b) you decide whether you want to
go off on a wild goose chase. You are in control in that case, not the browser.

I mention the browser analogy because everyone can relate to it. Its UI is
straightforward and commonsensical. What we're doing in Emacs now is not.

When you hit RET, you are telling Emacs, a browser, whatever: "This is what I
want. If you don't have that, then just say so."

Emacs has always allowed you, in some contexts (but not in others), to hit RET
to both complete and enter the completed text. But that becomes less appropriate
when the completion is not obvious from the input text (as is the case for
partial completion).

It's particularly problematic if the user's intention is that what s?he entered
be considered already complete. And we cannot know that intention for sure; we
can only suppose it because s?he chose to use RET, not TAB.

`C-h f' should either (a) forego `completion-styles' and use basic (prefix)
completion or (b) require confirmation when prefix completion fails and it moves
on to more exotic attempts to find something that matches.


[It is also unfriendly to users for Emacs TAB to perform such partial completion
by default, but TAB is a different story from RET. The mystery and
unexpectedness of the TAB behavior has already been documented as several other
bugs, and will no doubt continue to cause unwitting users to file bugs. I got a
mail from a user just yesterday who said with annoyance after discovering what
was happening, "suddenly you get lots of completion results which seemingly no
connection to what you've been typing". Indeed you do, indeed you do.]