Subject: bug#6756: closed (Re: bug#6756: 23.2; `describe-function' describing functions that aren't)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 31 Jul 2010 12:06:02 +0000

Your bug report

#6756: 23.2; `describe-function' describing functions that aren't

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
6756: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6756
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#6756: 23.2; `describe-function' describing functions that aren't
From: Juanma Barranquero <[email-masked]>
To: MON KEY <[email-masked]>
Cc: [email-masked]
Date: Sat, 31 Jul 2010 14:05:14 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

On Sat, Jul 31, 2010 at 04:50, MON KEY <[email-masked]> wrote:

> It would be working as expected assuming I could ascertain _what_ to
> expect.

I agree that completion is complex and perhaps underdocumented.

> FWIW I increasingly find it unreasonable that *Help* defaults to
> _just_ pointing the user to `customize'.

I haven't noticed that. I share your opinion on Customize, though.

> It isn't all that helpful that *Help* seems to increasingly
> (implicitly) suggest dropping into *Info* or custom to get help.

I think suggesting to read Info is reasonable. It does not make much
sense to duplicate in docstrings all the information already available
on the Info pages.

I'm closing this bug, as it is no longer about describe-function
failing. Feel free to file bugs about documentation shortcomings, etc.

    Juanma

Subject: 23.2; `describe-function' describing functions that aren't
From: MON KEY <[email-masked]>
To: [email-masked]
Date: Thu, 29 Jul 2010 13:22:22 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

When called interactively `describe-function' incorrectly completes on
non-existent functions with symbol-names suffixed with a `*' and
returns documentation for an equivalent non-suffixed version of
symbol-name (assuming it exists).

e.g. if the user enters "gensym*" at the `completing-read' prompt by
`describe-function' its return value is the documentation for symbol
`gensym'.

At first glance this would appear to be a DWIM type feature.
However,  I would argue that it is a bug  because:

 a) the completing-read arg PREDICATE is `fboundp' and REQUIRE-MATCH
    is t;

 b) the `*' suffixed symbol is not (neccesarily) `fboundp';

 c) the `*' suffixed symbol may not match;

 d) When there is no equivalent non `*' suffixed symbol
    `completing-read' returns "No match" e.g. if the user enters
    "blub*" at the `completing-read' and neither "blub*" nor "blub"
    are `fboundp';

 e) If the user enters any other equivalently suffixed symbol
    `completing-read' returns "No match" e.g. when the user enters the
    suffixed symbol names "gensym!", "gensym^", "gensym+", etc.  at
    the `completing-read' and none of these are `fboundp'

Note, in the examples above "gensym" is used as the base symbol-name
but this happens just as well for non CL fncns, e.g.  if the user
enters "describe-function*" at the `completing-read' prompt by
`describe-function' the return value is the documentation for symbol
`describe-function'.

Behaviour verified with 23.2 with emacs -Q

--
/s_P\