From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dave Goel Newsgroups: gmane.emacs.devel Subject: Re: find-file.el bug; checked in a fix. Date: Fri, 07 Dec 2007 13:50:22 -0500 Message-ID: <87hciue3v5.fsf@marie.gnufans.net> References: <874pewdc8c.fsf@marie.gnufans.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1197053451 28927 80.91.229.12 (7 Dec 2007 18:50:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Dec 2007 18:50:51 +0000 (UTC) To: "Richard M. Stallman" , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 07 19:51:00 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J0iHq-0005GU-3k for ged-emacs-devel@m.gmane.org; Fri, 07 Dec 2007 19:50:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0iHZ-0001hu-1Z for ged-emacs-devel@m.gmane.org; Fri, 07 Dec 2007 13:50:41 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J0iHV-0001g8-QV for emacs-devel@gnu.org; Fri, 07 Dec 2007 13:50:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J0iHV-0001fb-B5 for emacs-devel@gnu.org; Fri, 07 Dec 2007 13:50:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0iHV-0001fK-0n for emacs-devel@gnu.org; Fri, 07 Dec 2007 13:50:37 -0500 Original-Received: from mtai02.charter.net ([209.225.8.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J0iHR-0004Q0-Dm; Fri, 07 Dec 2007 13:50:33 -0500 Original-Received: from aarprv06.charter.net ([10.20.200.76]) by mtai02.charter.net (InterMail vM.7.08.03.00 201-2186-126-20070710) with ESMTP id <20071207185022.YPIU28.mtai02.charter.net@aarprv06.charter.net>; Fri, 7 Dec 2007 13:50:22 -0500 Original-Received: from marie.gnufans.net ([66.168.196.121]) by aarprv06.charter.net with ESMTP id <20071207185022.MDKJ14098.aarprv06.charter.net@marie.gnufans.net>; Fri, 7 Dec 2007 13:50:22 -0500 Original-Received: from deego by marie.gnufans.net with local (Exim 3.36 #1 (Debian)) id 1J0iHG-0000uy-00; Fri, 07 Dec 2007 13:50:22 -0500 X-Face: #5@=vrmx5t3mZaPY8(mR.n+V#:%4NW7j5A&^}@lGp2rK; CQ4%iH1v'gh/^A)w5*6c&R2(P' 4+seYDq8OK'LPI/C(C^A*w|f*t+8, 'T8b#_0~h3!A7GoVroE[cr0Fb'A0%SdU|Lk@gBV&1vA In-Reply-To: (Richard Stallman's message of "Fri, 07 Dec 2007 12:18:37 -0500") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-Chzlrs: 0 X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:84845 Archived-At: Richard Stallman writes: > If a function f is autoloaded from a file a.el in a directory d, and > if there also exists an executable file called a in a directory d1, > then calling find-function on f shows the file a instead of > a.el. > Does it actually matter that the file `a' is executable? You are right. That doesn't matter. > > The problem seems to appear when d1 precedes d in your extended load-path. > > Why is the file `a' present in a directory in the `load-path'? > Usually the directories in `load-path' just contain Lisp files. > Was the file `a' put in those directories for a good reason > or was it there by mistake? I agree with the "usually" part. You could say it was "my bad." Or you could say that in an era where emacs provides usability as a scripting language, I am increasingly using emacs (instead of say, bash or perl) as a scripting language for a large number of things. Thus, I freely mix bash scripts with elisp scripts, and they may call each other, pipe to or from each other, etc., the only difference is that the emacs scripts have #!/usr/local/bin/emacscvs --script at the beginning instead of #!/bin/bash. Thus, I have my emacs scripts lying around at a whole lot of places freely intermingling with bash scripts.. Furthermore, I want to make the utilities used by these scripts available to my running emacsen as well. Thus, these executable emacs-script files, say F, usually load a corresponding emacs library lying in the same directory called F.el, where utilities are defined. Thus, my bash load path and emacs load path share a large number of common directories. Often, I do what the script does, either through my running emacs, or through the bash executable in an xterm, depending on my "mood". You could say that for each such directory, I should perhaps make an emacs-specific subdirectory, and only provide that subdirectore to my emacs load-path so as to conform to the above convention you mentioned; I guess I have been too lazy till now. > > The problem is that symbol-function definition for loaded functions > does not store the .el suffix. > > This is done for a good reason -- so if the function was defined in > foo.elc.gz, you can find foo.el, foo.el.gz, or whatever is there. Agreed. > > I believe that an appropriate solution is to simply make > `find-library-name' search for the (".el" ".el.gz") files first in the > load-path. Only if it does not succeed look for the other suffixes. > > That might be a good solution. I do not feel sure of it, though. > > Another solution that might be more thoroughly correct is to retain > some of the info about the suffix that was actually loaded; > specifically, to figure out what suffix the source file _should_ have > had, and then load only that. That would be nice. It certainly wouldn't hurt to retain more information. > This might be more thoroughly correct, but it is also more risky. I agree with the "riskiness" assessment. Another problem is that depending on your machine's and GNU distribution's setup, the path where emacs loaded a function definition in a .elc may be completely different from the path where the corresponding .el resides. And, you want find-function to go to the .el, or even the .el.gz, as may be present. So, the current method of searching for the .el rather than specifying a complete path and extension, works pretty well. The only catch is that it is somewhat of a heuristic. The current tweak improves the heuristic. > So maybe your fix is the better choice. > > Does anyone else have an opinion about this? > > Meanwhile, I would like to know the specifics of the real test case > you encountered. What were the REAL names, and why was the executable > file in a directory in load-path? The actual filename was a script called trash somewhere in the loadpath. I also happened to have an unrelated emacs file trash.el. (see description of my setup above.)