Re: find-file.el bug; checked in a fix.

[Richard Stallman <rms@gnu.org>]

    If a function f is autoloaded from a file a.el in a directory d, and
    if there also exists an executable file called a in a directory d1,
    then calling find-function on f shows the file a instead of
    a.el.

Does it actually matter that the file `a' is executable?

    The problem seems to appear when d1 precedes d in your extended load-path.

Why is the file `a' present in a directory in the `load-path'?
Usually the directories in `load-path' just contain Lisp files.
Was the file `a' put in those directories for a good reason
or was it there by mistake?

    The problem is that symbol-function definition for loaded functions
    does not store the .el suffix.

This is done for a good reason -- so if the function was defined in
foo.elc.gz, you can find foo.el, foo.el.gz, or whatever is there.

    I believe that an appropriate solution is to simply make
    `find-library-name' search for the (".el" ".el.gz") files first in the
    load-path.  Only if it does not succeed look for the other suffixes.

That might be a good solution.  I do not feel sure of it, though.

Another solution that might be more thoroughly correct is to retain
some of the info about the suffix that was actually loaded;
specifically, to figure out what suffix the source file _should_ have
had, and then load only that.  This might be more thoroughly correct,
but it is also more risky.  So maybe your fix is the better choice.

Does anyone else have an opinion about this?

Meanwhile, I would like to know the specifics of the real test case
you encountered.  What were the REAL names, and why was the executable
file in a directory in load-path?