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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> But your patch also affects the case where find-function-source-path is nil.

> Yes. (And the current code ignores it even when it is non-nil. Actually,
> the current code ignores everything -- it simply tries the one single
> file name it guesses is right and either finds it or errors out.)

Indeed, the current code's exclusive use of absolute file names is not
correct either.  It's just the result of uncoordinated changes.

> OK, I think I get it, thank you very much for the explanation. Honestly,
> this kind of loading seems pathologic to me -- it never crossed my mind
> to load/require "path/file" instead of first adding "path" to
> `load-path' and then `load'ing "file". What use does this have? Or
> rather, is it necessary (I imagine people might be trying to use this as
> a poor man's module system)?

Given the fact that we need to make sure every file name's first 8 chars
are unique (for the MSDOS build), it can be sometimes very convenient.
Semantic uses it extensively.  It's not used as a module system, tho
it's somewhat used as a way to specify "packages" of modules.
It also has the advantage of limiting the growth of the load-path
directory, which might improve performance somewhat (probably
negligible, tho, on current machines).

> In any case, I'm obviously still missing a lot (such as how the case
> with symbols defined outside load-path is handled or how the Help cross
> references come into play -- they still don't work even with my "fix");
> I'll try to look at the code some more.


        Stefan