bug#6716: 23.2; Setting `find-function-source-path' has no effect.

["Štěpán Němec" <stepnem@gmail.com>]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Because `find-library-name' receives as its LIBRARY argument the full
>> path, but doesn't strip the directory part, setting
>> `find-function-source-path' has no effect on symbol finding -- Emacs
>> still tries the path guessed according to load path (which is not
>> correct in case you have the Elisp sources in directory different from
>> the compiled files).
>
> The file name has been changed to a full absolute name to avoid showing
> the wrong file when there's some shadowing going on.  So your patch
> would re-introduce this problem.

I don't think I understand -- setting `f-f-s-p' should provide means to
override the normal load-path search. I don't care if the source I jump
to is really "equivalent" to the version I have loaded (it might not be
anyway -- the symbol definition is often loaded from a byte-compiled file,
whereas the equivalent source file could have been changed since then).
The only thing I care about is to jump to the/a source *I want* (that's
why I set `f-f-s-p') for a symbol I search for. The current behaviour
is broken for any purpose I can think of (other than when the absolute
path is right, which is normally never the case with `f-f-s-p' set).

When you look at the current `find-library-name' definition, it's
_obviously_ wrong to pass an absolute file name to it. It just makes no
sense.

> Also, it may not work for files that were loaded as "foo/bar".  I think
> the load-history needs to be changed to keep track of both the absolute
> file name and the name used to load the file
> (i.e. "/bla/bla/foo/bar.elc" and "foo/bar").  Then in
> find-function-source-path we will first try for /bla/bla/foo/bar.el and
> when that fails we can fall back on searching for foo/bar.el.

I assume you meant `find-library-name', not `find-function-source-path'
in the last sentence.

I don't know if my fix is the best way to do it, but it fixes the bug
for me now and from your reply I'm not able to understand why it should
not be installed (for now, at least) or what concrete alternatives you
suggest (changing `load-history' implementation does not sound like
something that would be done any time soon -- or are you (or anybody)
going to do it?).


  Štěpán

>
>
>         Stefan
>
>
>> This simple change seems to fix it for me:
>
>> diff --git a/lisp/emacs-lisp/find-func.el b/lisp/emacs-lisp/find-func.el
>> index 216d91b..f704c63 100644
>> --- a/lisp/emacs-lisp/find-func.el
>> +++ b/lisp/emacs-lisp/find-func.el
>> @@ -150,10 +150,10 @@ (defun find-library-name (library)
>>    (if (string-match "\\.el\\(c\\(\\..*\\)?\\)\\'" library)
>>        (setq library (replace-match "" t t library)))
>>    (or 
>> -   (locate-file library
>> +   (locate-file (file-name-nondirectory library)
>>  		(or find-function-source-path load-path)
>>  		(find-library-suffixes))
>> -   (locate-file library
>> +   (locate-file (file-name-nondirectory library)
>>  		(or find-function-source-path load-path)
>>  		load-file-rep-suffixes)
>>     (error "Can't find library %s" library)))
>
>
>> Regards,
>
>>   Štěpán