* Skipping installation of .el.gz files @ 2023-10-23 0:45 Spencer Baugh 2023-10-23 5:55 ` Emanuel Berg ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Spencer Baugh @ 2023-10-23 0:45 UTC (permalink / raw) To: help-gnu-emacs 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? This is what it normally does when I run Emacs without installing it, so I expect it's possible. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-23 0:45 Skipping installation of .el.gz files Spencer Baugh @ 2023-10-23 5:55 ` Emanuel Berg 2023-10-23 6:41 ` Corwin Brust 2023-10-23 11:35 ` Eli Zaretskii 2 siblings, 0 replies; 14+ messages in thread From: Emanuel Berg @ 2023-10-23 5:55 UTC (permalink / raw) To: help-gnu-emacs Spencer Baugh wrote: > 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? > This is what it normally does when I run Emacs without > installing it, so I expect it's possible. Yes, but if you install it and run it it isn't run from there anymore but from the installed files, so why aren't them the ones you want to go to? -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-23 0:45 Skipping installation of .el.gz files Spencer Baugh 2023-10-23 5:55 ` Emanuel Berg @ 2023-10-23 6:41 ` Corwin Brust 2023-10-23 16:18 ` Spencer Baugh 2023-10-23 11:35 ` Eli Zaretskii 2 siblings, 1 reply; 14+ messages in thread From: Corwin Brust @ 2023-10-23 6:41 UTC (permalink / raw) To: Spencer Baugh; +Cc: help-gnu-emacs On Sun, Oct 22, 2023 at 7:45 PM Spencer Baugh <sbaugh@janestreet.com> wrote: > > Is there a clean and supported way to teach Emacs to jump to the files > in source-directory instead of the .el.gz ones? This is what it > normally does when I run Emacs without installing it, so I expect it's > possible. > > Do you need the el.gz versions if you will be hanging onto the uncompressed sources? If not, you might try configuring --without-compress-install ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-23 6:41 ` Corwin Brust @ 2023-10-23 16:18 ` Spencer Baugh 0 siblings, 0 replies; 14+ messages in thread From: Spencer Baugh @ 2023-10-23 16:18 UTC (permalink / raw) To: help-gnu-emacs Corwin Brust <corwin@bru.st> writes: > On Sun, Oct 22, 2023 at 7:45 PM Spencer Baugh <sbaugh@janestreet.com> wrote: > >> >> Is there a clean and supported way to teach Emacs to jump to the files >> in source-directory instead of the .el.gz ones? This is what it >> normally does when I run Emacs without installing it, so I expect it's >> possible. >> >> > Do you need the el.gz versions if you will be hanging onto the uncompressed > sources? If not, you might try configuring > > --without-compress-install Hm, this just causes the el.gz versions to be uncompressed. But they're still installed, rather than using source-directory. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-23 0:45 Skipping installation of .el.gz files Spencer Baugh 2023-10-23 5:55 ` Emanuel Berg 2023-10-23 6:41 ` Corwin Brust @ 2023-10-23 11:35 ` Eli Zaretskii 2023-10-23 12:28 ` Emanuel Berg 2023-10-23 16:42 ` Spencer Baugh 2 siblings, 2 replies; 14+ messages in thread From: Eli Zaretskii @ 2023-10-23 11:35 UTC (permalink / raw) To: help-gnu-emacs > From: Spencer Baugh <sbaugh@janestreet.com> > 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. Alternatively (not tested) tweak load-path to include the source tree's lisp/ directory and its subdirectories before the directory where Lisp files were installed. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-23 11:35 ` Eli Zaretskii @ 2023-10-23 12:28 ` Emanuel Berg 2023-10-28 10:44 ` Eli Zaretskii 2023-10-23 16:42 ` Spencer Baugh 1 sibling, 1 reply; 14+ messages in thread From: Emanuel Berg @ 2023-10-23 12:28 UTC (permalink / raw) To: help-gnu-emacs Eli Zaretskii wrote: >> 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. > Alternatively (not tested) tweak load-path to include the > source tree's lisp/ directory and its subdirectories before > the directory where Lisp files were installed. But those are the files used, it is better to do $ sudo find / -name \*.el.gz -exec gunzip -f -k {} \; and have the on-line help and what have you access those files. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-23 12:28 ` Emanuel Berg @ 2023-10-28 10:44 ` Eli Zaretskii 2023-10-28 10:52 ` Emanuel Berg 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2023-10-28 10:44 UTC (permalink / raw) To: help-gnu-emacs > From: Emanuel Berg <incal@dataswamp.org> > Date: Mon, 23 Oct 2023 14:28:10 +0200 > > But those are the files used, it is better to do > > $ sudo find / -name \*.el.gz -exec gunzip -f -k {} \; > > and have the on-line help and what have you access > those files. The help system can use the compressed files as well, so need to uncompress them. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-28 10:44 ` Eli Zaretskii @ 2023-10-28 10:52 ` Emanuel Berg 0 siblings, 0 replies; 14+ messages in thread From: Emanuel Berg @ 2023-10-28 10:52 UTC (permalink / raw) To: help-gnu-emacs Eli Zaretskii wrote: >> But those are the files used, it is better to do >> >> $ sudo find / -name \*.el.gz -exec gunzip -f -k {} \; >> >> and have the on-line help and what have you access >> those files. > > The help system can use the compressed files as well, so > need to uncompress them. So it can? Maybe I did that for some other reason then ... -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-23 11:35 ` Eli Zaretskii 2023-10-23 12:28 ` Emanuel Berg @ 2023-10-23 16:42 ` Spencer Baugh 2023-10-23 18:39 ` Eli Zaretskii 1 sibling, 1 reply; 14+ messages in thread From: Spencer Baugh @ 2023-10-23 16:42 UTC (permalink / raw) To: help-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: >> From: Spencer Baugh <sbaugh@janestreet.com> >> 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-23 16:42 ` Spencer Baugh @ 2023-10-23 18:39 ` Eli Zaretskii 2023-10-23 20:25 ` Spencer Baugh 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2023-10-23 18:39 UTC (permalink / raw) To: help-gnu-emacs > 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-23 18:39 ` Eli Zaretskii @ 2023-10-23 20:25 ` Spencer Baugh 2023-10-23 20:57 ` Emanuel Berg 2023-10-24 12:35 ` Eli Zaretskii 0 siblings, 2 replies; 14+ messages in thread From: Spencer Baugh @ 2023-10-23 20:25 UTC (permalink / raw) To: help-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: >> 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. Yes. And this is an issue today for jumping to the definitions of functions in C files, since those are not packaged with Emacs. Today, that is broken out of the box if source-directory is still around. So if you think this behavior is bad, then should we fix it to not happen for the case of C files? Perhaps by clearing source-directory when Emacs is installed, so that Emacs cannot find obsolete C files out of the Git repository? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-23 20:25 ` Spencer Baugh @ 2023-10-23 20:57 ` Emanuel Berg 2023-10-24 12:35 ` Eli Zaretskii 1 sibling, 0 replies; 14+ messages in thread From: Emanuel Berg @ 2023-10-23 20:57 UTC (permalink / raw) To: help-gnu-emacs Spencer Baugh wrote: >> 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. > > Yes. And this is an issue today for jumping to the > definitions of functions in C files, since those are not > packaged with Emacs. Today, that is broken out of the box if > source-directory is still around. > > So if you think this behavior is bad, then should we fix it > to not happen for the case of C files? Perhaps by clearing > source-directory when Emacs is installed, so that Emacs > cannot find obsolete C files out of the Git repository? When you say install, do you mean with a package manager? If so, shouldn't the Git files rather than obsolete be more updated than what you get from the distribution's repository? If you OTOH mean build from source, doesn't that mean the files and references to functions etc are always in sync with the files? Unless you get new source after that and then don't install it? But then the source again isn't obsolete, rather it belongs to the future compared to the install. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-23 20:25 ` Spencer Baugh 2023-10-23 20:57 ` Emanuel Berg @ 2023-10-24 12:35 ` Eli Zaretskii 2023-10-24 12:49 ` Emanuel Berg 1 sibling, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2023-10-24 12:35 UTC (permalink / raw) To: help-gnu-emacs > From: Spencer Baugh <sbaugh@janestreet.com> > Date: Mon, 23 Oct 2023 16:25:56 -0400 > > > 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. > > Yes. And this is an issue today for jumping to the definitions of > functions in C files, since those are not packaged with Emacs. Today, > that is broken out of the box if source-directory is still around. "Broken" is an exaggeration. C source files are less important that Lisp sources, and in many cases the C sources are not installed at all on the user's machine. I see no problem here. > So if you think this behavior is bad I didn't say it was bad, I said your suggestion for a change was not a good idea, since it would introduce a problem where currently there is none. > then should we fix it to not happen for the case of C files? > Perhaps by clearing source-directory when Emacs is installed, so > that Emacs cannot find obsolete C files out of the Git repository? This problem doesn't exist for most users, so I see no reason to fix something that isn't broken. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Skipping installation of .el.gz files 2023-10-24 12:35 ` Eli Zaretskii @ 2023-10-24 12:49 ` Emanuel Berg 0 siblings, 0 replies; 14+ messages in thread From: Emanuel Berg @ 2023-10-24 12:49 UTC (permalink / raw) To: help-gnu-emacs Eli Zaretskii wrote: > "Broken" is an exaggeration. C source files are less > important that Lisp sources, and in many cases the C sources > are not installed at all on the user's machine. I see no > problem here. If you want them, and want to be sure they will match, get the source, build Emacs and then don't touch them. If you don't do that, but still want them, feel free to get them from wherever and hook them up manually but then it is up to you to do that correctly if they will match perfectly or not. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-10-28 10:52 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-10-23 0:45 Skipping installation of .el.gz files Spencer Baugh 2023-10-23 5:55 ` Emanuel Berg 2023-10-23 6:41 ` Corwin Brust 2023-10-23 16:18 ` Spencer Baugh 2023-10-23 11:35 ` Eli Zaretskii 2023-10-23 12:28 ` Emanuel Berg 2023-10-28 10:44 ` Eli Zaretskii 2023-10-28 10:52 ` Emanuel Berg 2023-10-23 16:42 ` Spencer Baugh 2023-10-23 18:39 ` Eli Zaretskii 2023-10-23 20:25 ` Spencer Baugh 2023-10-23 20:57 ` Emanuel Berg 2023-10-24 12:35 ` Eli Zaretskii 2023-10-24 12:49 ` Emanuel Berg
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.