From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Suggestion for C-h f, describe-function Date: Sat, 01 Jul 2006 16:58:56 +0200 Message-ID: <85fyhlbccv.fsf@lola.goethe.zz> References: <85slllbpkb.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1151766002 19907 80.91.229.2 (1 Jul 2006 15:00:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 1 Jul 2006 15:00:02 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 01 17:00:00 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Fwgwu-0003jH-OG for ged-emacs-devel@m.gmane.org; Sat, 01 Jul 2006 16:59:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fwgwu-0002MG-91 for ged-emacs-devel@m.gmane.org; Sat, 01 Jul 2006 10:59:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fwgwi-0002KB-Qx for emacs-devel@gnu.org; Sat, 01 Jul 2006 10:59:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fwgwi-0002Jl-FX for emacs-devel@gnu.org; Sat, 01 Jul 2006 10:59:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fwgwi-0002Je-64 for emacs-devel@gnu.org; Sat, 01 Jul 2006 10:59:44 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fwh9j-0003L8-DZ for emacs-devel@gnu.org; Sat, 01 Jul 2006 11:13:11 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1Fwgwa-0004Wb-U6; Sat, 01 Jul 2006 10:59:37 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 438511C4D3B9; Sat, 1 Jul 2006 16:58:57 +0200 (CEST) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Sat, 01 Jul 2006 10:11:17 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:56350 Archived-At: Richard Stallman writes: > Hi, when using C-h f describe-function RET on a function defined in C, > the hyperlink with the source file name takes me to the Emacs source > code tree, which is very convenient. > > Doing the same on a Lisp function will instead take me to the actually > loaded file in the installed tree which is quite less convenient since > > I don't understand the distinction -- could you explain? ignore is an interactive compiled Lisp function in `subr.el'. It is bound to . (ignore &rest IGNORE) Do nothing and return nil. This function accepts any number of arguments, but ignores them. [back] If I use the hyperlink on `subr.el', it takes me to /usr/local/share/emacs/22.0.50/lisp/subr.el.gz which is the installed tree. Editing here is useless. Instead /usr/local/src/emacs/lisp/subr.el would have been more useful. In contrast: integerp is a built-in function in `C source code'. (integerp OBJECT) Return t if OBJECT is an integer. [back] Clicking on the `C source code' hyperlink takes me to /usr/local/src/emacs/src/data.c instead which is right in file under CVS control. > Are you talking about which directory is used? I tried to, yes. > We could make it try source-directory first, for Lisp files. > In case it works. The problem is with stuff compiled in another machine or another directory: if some user has an installed Emacs and uses the C source code link, the worst that can happen is that he gets landed in a nonsensical place instead of no place at all, since there is no C source code in the installed Emacs tree. With the Lisp code, there _is_ useful code for a user to jump to, so we don't have the situation "could as well do something wrong rather than nothing at all" here, and should be more careful about trying source-directory first when we don't know whether it points somewhere useful. In addition, there might be various external packages in their own CVS source trees (like AUCTeX). This can't happen in C, as Emacs has no C level module interface, but it would be nice if one could set one's Emacs up at least manually to have it know just where to find the source trees of stuff. Another possibility would be to have an option that would embed the source tree info into files that are byte-compiled. Then one could set this option in the Makefiles for "make install" when one knew that one was just using Emacs on one's own machine and not handing the binaries around. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum