Re: Skipping installation of .el.gz files

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Mon, 23 Oct 2023 12:42:31 -0400
> 
> Eli Zaretskii <eliz@gnu.org> 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.