From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Skipping installation of .el.gz files Date: Mon, 23 Oct 2023 21:39:20 +0300 Message-ID: <83ttqhmbdz.fsf@gnu.org> References: <83wmvdo9ks.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35884"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 23 20:40:02 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 1quzqM-00097b-5A for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 23 Oct 2023 20:40:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1quzpe-0002RC-OA; Mon, 23 Oct 2023 14:39:18 -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 1quzpd-0002R2-SN for help-gnu-emacs@gnu.org; Mon, 23 Oct 2023 14:39:17 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1quzpd-0004c3-Ig for help-gnu-emacs@gnu.org; Mon, 23 Oct 2023 14:39:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rBUSFANmu7fzNp3/h27QknkuXPiJQUu4rDCAfxxs9jE=; b=ZVWFWsaNBRZ2 0jsNqweeII6oOBAnnzsGzZ5HG9SEZxvF86oW69fory1KdEymZ9AzK8Fo81Q7Up01Kx3EkuNiIXKxN kQiYyCWIT4PqDV6+Pncbc/t8VeoyR1hCCW2PLr/zlmGjFP7EhjCNLq17CZM9rDE1pfRQJBKYN0dw4 VnAoKgepLrRqf4hRgF+ESFl0Rg4nPa4x7XiLMxm50mgMW+0Mi8qq+mGah62V7g1Hb7hhymCQdUqs2 RLEYFKfewV68b89nWCHhyhihgL4v9ni2YNARTHP6/kL42RQsZsHQQ5wGBDTmbSK3CBXPrj4gFjQ9d Dg1PgXgVGDCE8I7L2I9RiA==; In-Reply-To: (message from Spencer Baugh on Mon, 23 Oct 2023 12:42:31 -0400) 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:145363 Archived-At: > From: Spencer Baugh > Date: Mon, 23 Oct 2023 12:42:31 -0400 > > Eli Zaretskii writes: > > > > 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. No, because the source directory could hold code different from the one which was used to install the files under /usr/share. Think about Emacs installed from a Git repository that got many updates after that, for example. > 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? No, see above. You took a very special situation caused by your local procedures, and generalize it under the (false) assumption that it will be necessary useful for everyone. The current logic of looking for source files wasn't borne yesterday, so we should respect it a bit more, and if it sometimes sounds that it could be easily changed to be much smarter, it is usually a sign that we are missing something. You asked how to solve your specific situation, and got several useful responses. Why not implement them in your local sandbox and be done? There's no reason to immediately consider the upstream code wrong just because you did something that the Emacs installation doesn't support, and cannot support without causing problems in other, currently supported, use cases.