From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.help Subject: Re: Skipping installation of .el.gz files Date: Mon, 23 Oct 2023 12:42:31 -0400 Message-ID: References: <83wmvdo9ks.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8414"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:LLHA+INazBAzaHAweoiCqcv70yk= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 23 18:42:56 2023 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1quy12-0001y5-AZ for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 23 Oct 2023 18:42:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1quy0r-0006iR-C9; Mon, 23 Oct 2023 12:42:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1quy0o-0006i6-Sb for help-gnu-emacs@gnu.org; Mon, 23 Oct 2023 12:42:42 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1quy0n-0007aH-4d for help-gnu-emacs@gnu.org; Mon, 23 Oct 2023 12:42:42 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1quy0l-0001dF-1F for help-gnu-emacs@gnu.org; Mon, 23 Oct 2023 18:42:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:145362 Archived-At: Eli Zaretskii writes: >> From: Spencer Baugh >> Date: Sun, 22 Oct 2023 20:45:46 -0400 >> >> >> At my site, I'd like to install the Emacs source code along with Emacs >> and set source-directory, so that users can easily jump to function >> definitions and search the Emacs source. >> >> This works great for C function definitions, but Lisp function >> definitions still jump to the .el.gz files which are installed by "make >> install". If I delete those files, jumping to Lisp function definitions >> stops working entirely. >> >> Is there a clean and supported way to teach Emacs to jump to the files >> in source-directory instead of the .el.gz ones? > > I suggest to override find-lisp-object-file-name with a similar > definition that does what you want. Hm, I think what it should do is just, when looking for a Lisp file such as /usr/share/emacs/29.1/lisp/files.elc, if /usr/share/emacs/29.1/lisp/files.el and /usr/share/emacs/29.1/lisp/files.el.gz don't exist, then also check for (concat source-directory "lisp/files.el") and use that if it exists. Only for Lisp files in the Emacs installation directory, of course. This seems generally useful for any user who compiles Emacs from source, installs it, and then keeps the source directory around. Now they can skip installing a duplicate copy of the Lisp files and wasting space, plus if they choose to do that, then when they jump to definition it will go directly to the source directory, which is how it already works for C definitions. Since this is generally useful, could this be an acceptable patch for upstream? Or some variation on it? Any suggestions on how to reliably figure out the Emacs installation directory for Lisp files? I think PATH_LOADSEARCH is what I want, but that's not exposed to Lisp currently.