GNU bug report logs -
#4718
23.1; C-h f gives doc for the wrong function
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Wed, 14 Oct 2009 00:00:06 UTC
Severity: normal
Tags: wontfix
Done: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> 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
This bug report was last modified 13 years and 314 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.