GNU bug report logs - #4718
23.1; C-h f gives doc for the wrong function

Previous Next

Package: emacs;

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: <4718 <at> debbugs.gnu.org>,
        "'Juanma Barranquero'" <lekktu <at> gmail.com>
Subject: bug#4718: 23.1; C-h f gives doc for the wrong function
Date: Wed, 14 Oct 2009 09:40:50 -0400
> 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.