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: Mon, 26 Jul 2010 06:17:34 +0200 Message-ID: <87zkxeev1d.fsf@gmail.com> References: <874ofpqeiu.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 1280119094 31915 80.91.229.12 (26 Jul 2010 04:38:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 26 Jul 2010 04:38:14 +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 Mon Jul 26 06:38:13 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 1OdFS8-0000yJ-Dd for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Jul 2010 06:38:12 +0200 Original-Received: from localhost ([127.0.0.1]:33737 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OdFS7-00081v-TT for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Jul 2010 00:38:11 -0400 Original-Received: from [140.186.70.92] (port=52301 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OdFRg-0007s8-1R for bug-gnu-emacs@gnu.org; Mon, 26 Jul 2010 00:37:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OdFRZ-0000Wm-Gz for bug-gnu-emacs@gnu.org; Mon, 26 Jul 2010 00:37:43 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36942) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OdFRZ-0000Wf-FJ for bug-gnu-emacs@gnu.org; Mon, 26 Jul 2010 00:37:37 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OdF9Z-0006fP-Ou; Mon, 26 Jul 2010 00:19:01 -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: Mon, 26 Jul 2010 04:19:01 +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.128011792725618 (code B ref 6716); Mon, 26 Jul 2010 04:19:01 +0000 Original-Received: (at 6716) by debbugs.gnu.org; 26 Jul 2010 04:18:47 +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 1OdF9L-0006f9-Al for submit@debbugs.gnu.org; Mon, 26 Jul 2010 00:18:47 -0400 Original-Received: from mail-pz0-f44.google.com ([209.85.210.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OdF9J-0006f3-5P for 6716@debbugs.gnu.org; Mon, 26 Jul 2010 00:18:45 -0400 Original-Received: by pzk6 with SMTP id 6so889120pzk.3 for <6716@debbugs.gnu.org>; Sun, 25 Jul 2010 21:18:48 -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=BZBoO9KNlKdit9hs45qFkvmE4UlAl5UEyNH0hHZGzRo=; b=ANfKjnoEkYDOGlpK/v1VCF/GVrXPArwXLnOqTcqmXrifasBKH94keP9Bpxv3FCQnE/ SceU3Ql0p04oh6vrI36Uvi5SR5QzeZ+6X1kRMTwIvu5+LIj3UbhUCf+UCk5oQc93+k5o pA5Xs+Avs78uaIbm6v1RGnBuZpSBk14YIYQOg= 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=HuDqjoo7DHPvKBoapx90o9e0DlI7Mp6srBX7/zV2UT//1cXeKgcHWBZXX88QiA+5bC 1Jrl9Egyo2nOq/5F6EyujSExHpkm43UlwhTSiggD01ZfwxN0QA1oFvbvNpjcQ+GRRCMz 6iqbw5VbsyDl5y6NG/HsD3Y98mIuL0tKhIoh0= Original-Received: by 10.142.229.13 with SMTP id b13mr8383173wfh.166.1280117928639; Sun, 25 Jul 2010 21:18:48 -0700 (PDT) Original-Received: from localhost ([88.103.132.186]) by mx.google.com with ESMTPS id l36sm1593978rvb.18.2010.07.25.21.18.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 25 Jul 2010 21:18:47 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Mon, 26 Jul 2010 01:45:13 +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: Mon, 26 Jul 2010 00:19:01 -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:38932 Archived-At: Stefan Monnier writes: >> Because `find-library-name' receives as its LIBRARY argument the full >> path, but doesn't strip the directory part, setting >> `find-function-source-path' has no effect on symbol finding -- Emacs >> still tries the path guessed according to load path (which is not >> correct in case you have the Elisp sources in directory different from >> the compiled files). > > The file name has been changed to a full absolute name to avoid showing > the wrong file when there's some shadowing going on. So your patch > would re-introduce this problem. I don't think I understand -- setting `f-f-s-p' should provide means to override the normal load-path search. I don't care if the source I jump to is really "equivalent" to the version I have loaded (it might not be anyway -- the symbol definition is often loaded from a byte-compiled file, whereas the equivalent source file could have been changed since then). The only thing I care about is to jump to the/a source *I want* (that's why I set `f-f-s-p') for a symbol I search for. The current behaviour is broken for any purpose I can think of (other than when the absolute path is right, which is normally never the case with `f-f-s-p' set). When you look at the current `find-library-name' definition, it's _obviously_ wrong to pass an absolute file name to it. It just makes no sense. > Also, it may not work for files that were loaded as "foo/bar". I think > the load-history needs to be changed to keep track of both the absolute > file name and the name used to load the file > (i.e. "/bla/bla/foo/bar.elc" and "foo/bar"). Then in > find-function-source-path we will first try for /bla/bla/foo/bar.el and > when that fails we can fall back on searching for foo/bar.el. I assume you meant `find-library-name', not `find-function-source-path' in the last sentence. I don't know if my fix is the best way to do it, but it fixes the bug for me now and from your reply I'm not able to understand why it should not be installed (for now, at least) or what concrete alternatives you suggest (changing `load-history' implementation does not sound like something that would be done any time soon -- or are you (or anybody) going to do it?). =C5=A0t=C4=9Bp=C3=A1n > > > Stefan > > >> This simple change seems to fix it for me: > >> diff --git a/lisp/emacs-lisp/find-func.el b/lisp/emacs-lisp/find-func.el >> index 216d91b..f704c63 100644 >> --- a/lisp/emacs-lisp/find-func.el >> +++ b/lisp/emacs-lisp/find-func.el >> @@ -150,10 +150,10 @@ (defun find-library-name (library) >> (if (string-match "\\.el\\(c\\(\\..*\\)?\\)\\'" library) >> (setq library (replace-match "" t t library))) >> (or=20 >> - (locate-file library >> + (locate-file (file-name-nondirectory library) >> (or find-function-source-path load-path) >> (find-library-suffixes)) >> - (locate-file library >> + (locate-file (file-name-nondirectory library) >> (or find-function-source-path load-path) >> load-file-rep-suffixes) >> (error "Can't find library %s" library))) > > >> Regards, > >> =C5=A0t=C4=9Bp=C3=A1n