[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12149: 24.1; `C-h f' is worse and worse at telling where a function
bug#12149: 24.1; `C-h f' is worse and worse at telling where a function was defined
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)
(prog1 (1on1-ORIG-y-or-n-p prompt)
(or (fboundp '1on1-ORIG-top-level)
(fset '1on1-ORIG-top-level (symbol-function 'top-level)))
(defun top-level ()
"Exit all recursive editing levels."
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
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
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
`configure --with-gcc (4.6) --cflags
|[Prev in Thread]
||[Next in Thread]|
- bug#12149: 24.1; `C-h f' is worse and worse at telling where a function was defined,
Drew Adams <=