all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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  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  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 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

* 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

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.