bug#24697: 25.1; find-lisp-object-file-name may return wrong locations

[Dmitry Gutov]

On 6/19/17 5:59 AM, Alex wrote:

> > Thanks. Do you think you can write test cases for these problems? There are some
> > existing ones in test/lisp/help-fns-tests.el.
>
> Sure, I've attached a patch below for the simple cases. As I couldn't
> find a satisfactory way to make a temporary face, I just made an
> uninterned symbol that find-lisp-object-file-name would treat as an
> internal variable.

Thanks.

Now, the patch looks correct to me, but did you encounter a practical 
problem that prompted you to look into this discrepancy? I'd like to 
know what it was.

> > With a test case, you might also find it easier to make a choice regarding this
> > problem.
>
> I'm not sure. I still don't understand why the design decision was made.
> I suppose one benefit is that one can search explicitly for internal
> functions rather than lisp functions, but the function could have just
> accepted 'subr instead of 'defun to do that.

There is a FIXME comment with the same question there. So you are not 
alone in wondering.

> Perhaps the current use of searching with TYPE should be left in for
> backwards compatibility (a Github search shows at least 2 instances of
> 3rd-party code that makes use of that behaviour).
>
> For instance, here's how you find mapatoms' file:
>
>    (find-lisp-object-file-name 'mapatoms (symbol-function 'mapatoms))
>
> You should just be able to do the following:
>
>    (find-lisp-object-file-name 'mapatoms 'defun)
>
> Or without searching for lisp functions named mapatoms first:
>
>    (find-lisp-object-file-name 'mapatoms 'subr)
>
> What do you think?

Maybe you're right, but backward compatibility seems important here as 
well. You're talking about a separate change, right? We could consider 
it for Emacs 27.