GNU bug report logs - #12149
24.1; `C-h f' is worse and worse at telling where a function was defined

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12149 in the body.
You can then email your comments to 12149 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.1;
	`C-h f' is worse and worse at telling where a function was defined
Date: Mon, 6 Aug 2012 10:49:15 -0700

I have this code:
 
(defun 1on1-setup-minibuffer-frame-coloring ()
  "Redefine some built-in functions so they color the minibuffer frame.
Functions redefined: `y-or-n-p', `top-level', `abort-recursive-exit'."
 
  (or (fboundp '1on1-ORIG-y-or-n-p)
      (fset '1on1-ORIG-y-or-n-p (symbol-function 'y-or-n-p)))
 
  (defun y-or-n-p (prompt)
    "Ask user a \"y or n\" question.  Return t if answer is \"y\".
Takes one argument, which is the string to display to ask the question.
It should end in a space; `y-or-n-p' adds `(y or n) ' to it.
No confirmation of answer is requested; a single character is enough.
Also accepts SPC to mean yes, or DEL to mean no."
    (if (> (minibuffer-depth) 0)
        (1on1-ORIG-y-or-n-p prompt)
      (1on1-color-minibuffer-frame-on-setup)
      (prog1 (1on1-ORIG-y-or-n-p prompt)
        (1on1-color-minibuffer-frame-on-exit))))
 

  (or (fboundp '1on1-ORIG-top-level)
      (fset '1on1-ORIG-top-level (symbol-function 'top-level)))
 
  (defun top-level ()
    "Exit all recursive editing levels."
    (interactive)
    (1on1-color-minibuffer-frame-on-exit)
    (1on1-ORIG-top-level))
 
...)
 
In Emacs prior to Emacs 23, `C-h f' did not point to the wrong files
as having defined these function.  At least it did not lie and steer
you wrong.
 
Emacs 23.4 did not point to the wrong file for `y-or-n-p', but it did
point to the wrong file for `top-level'.
 
Emacs 24.1 gets them both wrong.  It simply gives the original location
(from emacs -Q) for each of them: `C source code' for `top-level' and
`subr.el' for `y-or-n-p'.  This is not good.  Better to say "no idea"
than to mislead the user this way.
 
Instead of improving locating function definitions, things have gotten
worse.
 

In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600)
 of 2012-06-10 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

Message #8 received at 12149 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <12149 <at> debbugs.gnu.org>
Subject: RE: bug#12149: 24.1;
	`C-h f' is worse and worse at telling where a function was defined
Date: Sun, 16 Sep 2012 16:35:37 -0700

ping

Message #11 received at 12149 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 12149 <at> debbugs.gnu.org
Subject: Re: bug#12149: 24.1;
 `C-h f' is worse and worse at telling where a function was defined
Date: Thu, 28 Apr 2016 18:20:14 +0200

"Drew Adams" <drew.adams <at> oracle.com> writes:

> In Emacs prior to Emacs 23, `C-h f' did not point to the wrong files
> as having defined these function.  At least it did not lie and steer
> you wrong.
>
> Emacs 23.4 did not point to the wrong file for `y-or-n-p', but it did
> point to the wrong file for `top-level'.
>
> Emacs 24.1 gets them both wrong.  It simply gives the original location
> (from emacs -Q) for each of them: `C source code' for `top-level' and
> `subr.el' for `y-or-n-p'.  This is not good.  Better to say "no idea"
> than to mislead the user this way.

(progn
  (defun yes-or-no-p (prompt) (y-or-n-p prompt))
  (describe-function  'yes-or-no-p))

=>

yes-or-no-p is a Lisp function.

(yes-or-no-p PROMPT)

Not documented.

So I seem to be unable to reproduce this bug.  Are you still seeing it?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #14 received at 12149 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12149 <at> debbugs.gnu.org
Subject: RE: bug#12149: 24.1; `C-h f' is worse and worse at telling where a
 function was defined
Date: Thu, 28 Apr 2016 09:34:39 -0700 (PDT)

Whatever.

Lots of users mention that `C-h f' is worse and worse at telling
where a function was defined.  Closing the bug won't change that.

Message #17 received at 12149 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <nrichard <at> ulb.ac.be>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 12149 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12149: 24.1;
 `C-h f' is worse and worse at telling where a function was defined
Date: Thu, 28 Apr 2016 23:31:45 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

> Whatever.
>
> Lots of users mention that `C-h f' is worse and worse at telling
> where a function was defined.  Closing the bug won't change that.

You report a bug, someone says they can't reproduce and asks if you
still see it, and this is your answer ? Perhaps this is a case of
culture clash, perhaps I see problems where there are none, but atm I'm
really wondering why you are acting so negatively.

I guess the answer lies somewhere within the many years of archives of
the various emacs-related mailing lists, but to the young ignorant eye
(like mine), your answers oftentimes... look really weird.

I'm aware this message is pretty much out of the topic, so feel free (of
course) to ignore or respond privately if you like.

Anyway, back to the topic, I tried loading a file test.el with content:

(defun do-silly-things nil
  (defun scroll-up (&optional arg)
    "Do nothing and pretend all is fine."
    t))

(provide 'test)

then run "emacs -Q -l test -f do-silly-things" and finally describe the
function scroll-up. The result was that emacs did not tell where the
function is defined, only that it's a Lisp function/closure. i.e. this
matches what Lars said.

-- 
Nicolas

Message #20 received at 12149 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Nicolas Richard <nrichard <at> ulb.ac.be>
Cc: 12149 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#12149: 24.1;
 `C-h f' is worse and worse at telling where a function was defined
Date: Fri, 29 Apr 2016 22:23:29 +0200

Nicolas Richard <nrichard <at> ulb.ac.be> writes:

> Anyway, back to the topic, I tried loading a file test.el with content:
>
> (defun do-silly-things nil
>   (defun scroll-up (&optional arg)
>     "Do nothing and pretend all is fine."
>     t))
>
> (provide 'test)
>
> then run "emacs -Q -l test -f do-silly-things" and finally describe the
> function scroll-up. The result was that emacs did not tell where the
> function is defined, only that it's a Lisp function/closure. i.e. this
> matches what Lars said.

Thanks for checking, Nicolas.

This has probably been fixed after Drew's bug report.  Closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.