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

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

[Drew Adams]

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'
 

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

[Drew Adams]

ping

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

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@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

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

[Drew Adams]

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.

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

[Nicolas Richard]

Drew Adams <drew.adams@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

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

[Lars Ingebrigtsen]

Nicolas Richard <nrichard@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