[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: find-file.el bug; checked in a fix.
From: |
Dave Goel |
Subject: |
Re: find-file.el bug; checked in a fix. |
Date: |
Fri, 07 Dec 2007 13:50:22 -0500 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
Richard Stallman <address@hidden> 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.)