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

[Dave Goel <deego3@gmail.com>]

Richard Stallman <rms@gnu.org> writes:

>     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?

You are right.  That doesn't matter. 

>
>     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?

I agree with the "usually" part.  You could say it was "my bad."  Or
you could say that in an era where emacs provides usability as a
scripting language, I am increasingly using emacs (instead of say,
bash or perl) as a scripting language for a large number of things.
Thus, I freely mix bash scripts with elisp scripts, and they may call
each other, pipe to or from each other, etc., the only difference is
that the emacs scripts have #!/usr/local/bin/emacscvs --script at the
beginning instead of #!/bin/bash.

Thus, I have my emacs scripts lying around at a whole lot of places
freely intermingling with bash scripts.. Furthermore, I want to make
the utilities used by these scripts available to my running emacsen as
well. Thus, these executable emacs-script files, say F, usually load a
corresponding emacs library lying in the same directory called F.el,
where utilities are defined.  Thus, my bash load path and emacs load
path share a large number of common directories.  Often, I do what the
script does, either through my running emacs, or through the bash
executable in an xterm, depending on my "mood".

You could say that for each such directory, I should perhaps make an
emacs-specific subdirectory, and only provide that subdirectore to my
emacs load-path so as to conform to the above convention you
mentioned; I guess I have been too lazy till now.


>
>     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.

Agreed.

>
>     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.  

That would be nice.  It certainly wouldn't hurt to retain more
information.

> This might be more thoroughly correct, but it is also more risky.

I agree with the "riskiness" assessment.  Another problem is that
depending on your machine's and GNU distribution's setup, the path
where emacs loaded a function definition in a .elc may be completely
different from the path where the corresponding .el resides.  And, you
want find-function to go to the .el, or even the .el.gz, as may be
present.  So, the current method of searching for the .el rather than
specifying a complete path and extension, works pretty well.  The only
catch is that it is somewhat of a heuristic.  The current tweak
improves the heuristic.

> 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?

The actual filename was a script called trash somewhere in the
loadpath.  I also happened to have an unrelated emacs file trash.el.
(see description of my setup above.)