GNU bug report logs -
#6716
23.2; Setting `find-function-source-path' has no effect.
Previous Next
Reported by: Štěpán Němec <stepnem <at> gmail.com>
Date: Sat, 24 Jul 2010 11:58:02 UTC
Severity: normal
Tags: moreinfo
Found in version 23.2
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>>> 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.
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.)
>> (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.
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)?
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.
Štěpán
This bug report was last modified 3 years and 90 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.