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

[Dmitry Gutov <dgutov@yandex.ru>]

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.