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

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

[Dave Goel]

hi

Bug in the current cvs:

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. (And, it then fails to find the function f in the incorrectly
loaded file.)

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

----
I have checked in a fix -- 

The problem is that symbol-function definition for loaded functions
does not store the .el suffix.  locate-library then searches for all
suffixes ("el" "el.gz" "" ) in the load-path.  Given this order, it
does the right thing - prefer "el" over "" in a *given* directory.
However, this will fail if the "" suffix occurs in a different
directory which gets examined earlier. 

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.

The rationale is that it is much more likely that emacs would have
learned of that function from a ".el" (or a derivative thereof, like a
.elc) rather than a "" file.



I have committed this fix.


----

This seems like a pretty non-destructive and local change. `find-library-name',
not to be confused by locate-library, is only used in find-file.el.

-----

(I am posting here after years.  You all know me as D. Goel or Deepak
Goel or deego from my older email address which I no longer use
actively. I don't want to frob my From: header every time I post here;
so I am going to remark about the change here, and leave my From:
intact; I should learn about gnus posting styles...)


- Deepak Goel

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

[Richard Stallman]

    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?

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

[Dave Goel]

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