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
>> 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
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.