From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?=C5=A0t=C4=9Bp=C3=A1n_?= =?UTF-8?Q?N=C4=9Bmec?= Newsgroups: gmane.emacs.bugs Subject: bug#6716: 23.2; Setting `find-function-source-path' has no effect. Date: Tue, 27 Jul 2010 12:07:45 +0200 Message-ID: <87aapddyq6.fsf@gmail.com> References: <874ofpqeiu.fsf@gmail.com> <87zkxeev1d.fsf@gmail.com> <87mxteebg8.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1280227073 6276 80.91.229.12 (27 Jul 2010 10:37:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 27 Jul 2010 10:37:53 +0000 (UTC) Cc: 6716@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 27 12:37:51 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OdhXh-00041b-Sb for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Jul 2010 12:37:50 +0200 Original-Received: from localhost ([127.0.0.1]:45135 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OdhXh-00083T-7t for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Jul 2010 06:37:49 -0400 Original-Received: from [140.186.70.92] (port=46744 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OdhXZ-00082T-GT for bug-gnu-emacs@gnu.org; Tue, 27 Jul 2010 06:37:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OdhXW-00033u-B5 for bug-gnu-emacs@gnu.org; Tue, 27 Jul 2010 06:37:41 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54564) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OdhXW-00033S-9D for bug-gnu-emacs@gnu.org; Tue, 27 Jul 2010 06:37:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Odh5q-0003XH-9u; Tue, 27 Jul 2010 06:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?=C5=A0t=C4=9Bp=C3=A1n_?= =?UTF-8?Q?N=C4=9Bmec?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 27 Jul 2010 10:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6716 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6716-submit@debbugs.gnu.org id=B6716.128022533613584 (code B ref 6716); Tue, 27 Jul 2010 10:09:02 +0000 Original-Received: (at 6716) by debbugs.gnu.org; 27 Jul 2010 10:08:56 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Odh5j-0003X3-Em for submit@debbugs.gnu.org; Tue, 27 Jul 2010 06:08:55 -0400 Original-Received: from mail-px0-f172.google.com ([209.85.212.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Odh5h-0003Wx-Oz for 6716@debbugs.gnu.org; Tue, 27 Jul 2010 06:08:54 -0400 Original-Received: by pxi20 with SMTP id 20so359430pxi.3 for <6716@debbugs.gnu.org>; Tue, 27 Jul 2010 03:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :in-reply-to:references:user-agent:date:message-id:mime-version :content-type:content-transfer-encoding; bh=kMnXYqKxwwYcBKtKFGTfb6lTJXrUCQJl7rcvA6mwTyI=; b=JutvilOK2yVqXQGH2VYg16qbW4YNRw2srcBV6KZgMzPd5pT2zOYmXqtf/uTn+UqXf7 21ATLL2E+TSOWs+6q+7yEqgXROJsDjz4dIavwBYhTFrg2VjcHjnYcOpKNRo3FPhQ65Yw giABbdPF/2DbRvWoy/g+I0CpptPLY07LhK60s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type:content-transfer-encoding; b=ChwW7x6SAibiExj16q0Ln1QLbzmWfU7kv8psyXXghluVwZEga7VfdYuGvkE31OE2aK 3LDhooyG7EfinSubyrZv3eoh7CZo6dzHVp9xsOQo3fdNdouEz4IR3bXQbAVCidcPzcPu 5IpmKHSwEksdZhxYjLs6ruouA9zVrNZt9WXZI= Original-Received: by 10.142.199.20 with SMTP id w20mr3335844wff.291.1280225340792; Tue, 27 Jul 2010 03:09:00 -0700 (PDT) Original-Received: from localhost ([88.103.132.186]) by mx.google.com with ESMTPS id z1sm5419188wfd.15.2010.07.27.03.08.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 03:08:59 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Mon, 26 Jul 2010 23:44:20 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 27 Jul 2010 06:09:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:38975 Archived-At: Stefan Monnier 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 n= il. 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. =C5=A0t=C4=9Bp=C3=A1n