bug#72787: 31.0.50; Invalid describe-function completion candidates

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> Actually, it's not so much for the case where you know you want to see
>> `foo-bar` (which should be handled by `help-enable-symbol-autoload`
>> already) but also to let you discover that there might be a `foo-bar`
>> because there's a `foo-`.
>
> I see, so this is meant as a hint that should aid with discoverability.

Yes.  Sometimes that works via *Completions* (i.e. it requires the user
to see the `foo-` entry and understand that it means there's something
with this prefix), but sometimes it works without it, e.g. when you do
`C-h f trac-ch TAB` which completes to `track-changes-` after which
the next TAB will show you the possible completions.

> Perhaps annotating these prefix candidates could make that more obvious:
> I'm not sure that seeing "foo-" in *Completions* immediately suggests
> "try to complete this prefix to see more candidates".

Agreed.

> Personally I don't see this use case as important enough to break the
> invariant that completion candidates are valid inputs, so I'd go a
> different route.  The ability to load possibly-relevant libraries from
> within the minibuffer is great, but I think that providing a command
> that does that on demand would provide the same benefits.  Basically,
> you would press a key when you want to check if some unloaded maybe
> library defines something relevant.  Such a command could take into
> account the current minibuffer input, so it can be as efficient as the
> current facility. I can share a prototype if that sounds intriguing.

The intention of the current behavior is to be a bit more transparent
and try to approximate the illusion of having `C-h o` (I personally
never use `C-h v` of `C-h f` any more) give information about any
function/variable defined in any of the installed packages, rather than
only in the currently loaded set of files.


        Stefan