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

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

>> There lies the problem.  Other people do.  So the fix to your problem
>> will need to satisfy both cases.
> But if you care about that, you don't need `find-function-source-path'
> at all, no?

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

> (And actually, I don't see a reliable way to jump to the
> "right" source of a byte-compiled function in general (as I already
> pointed out in the previous mail).)

It doesn't have to work right when it's not possible.  But in the normal
case where the .el and the .elc files are in the same directory and the
.elc is the byte-compiled version of the .el file, it should work right.

> Also, you replied to none of my other questions, notably -- do you
> really (_really_) plan to reimplement `load-history', or was that just a
> "would be nice to have"?

I didn't say "reimplement".  Just that it needs to be tweaked with more
info.  We've changed it several times in the past, there's nothing
particularly tricky about that.

> If the latter, could you propose a better solution that would improve
> the current situation? (I'm sorry, but as I also already wrote,
> I didn't really understand the point(s) you were making.)

Some directories are not in the load-path, because the files therein are
expected to be loaded via something like (require 'semantic/sort) or
(load "term/vt100"), so if you see /blib/blob/semantic/sort.elc in the
load-history, you can't just take "sort.elc" and look for "sort.el" on
load-path because you'll find a completely unrelated file.


        Stefan