source-directory, installed Emacs, and C source

source-directory, installed Emacs, and C source

[sbaugh]

When Emacs is installed, it remembers the absolute file name of its
source code in source-directory.  And this is used to jump to C function
definitions.

This means if a user installs Emacs out of a Git repository and then the
user updates that Git repository, Emacs will jump to newer C
function definitions.  Namely, Emacs will jump to whatever's currently
in the Git repository rather than what actually was used to compile
Emacs.  (Thank you Eli for pointing this out.)

I see two mutually exclusive interpretations here:

- Jumping to a newer function definition is a problem.

  So we shouldn't be doing it for C.  We can do that by having Emacs
  forget the original source-directory when it's installed.  Probably
  also we should support installing C source files along with Emacs, to
  make up for forgetting source-directory.

  This would be a great improvement for users who don't keep
  source-directory around (since there's now an easy way to install C
  source along with Emacs), and a minor improvement for users that do
  keep source-directory around (since the C function definitions will
  now always match what's used to build Emacs)

- Jumping to a newer function definition is not a problem.

  So we can do it for Lisp too.  We can do that by having Emacs jump to
  Lisp source files from source-directory, too, if they exist.
  (Possibly as an option off by default, if people would prefer that)

  This would be a great improvement for users who keep source-directory
  around (since now Emacs jumps straight to your source repo, allowing
  easy modifications, and also you can skip installing Lisp source files
  with Emacs) and status quo for users that don't keep source-directory
  around.

Thoughts?

I'm interested in implementing one of these two options, since I want to
be able to reliably jump to function definitions from an installed
Emacs.  I don't care which of the two we go with.

Re: source-directory, installed Emacs, and C source

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Tue, 24 Oct 2023 10:31:49 -0400
> 
> - Jumping to a newer function definition is not a problem.
> 
>   So we can do it for Lisp too.  We can do that by having Emacs jump to
>   Lisp source files from source-directory, too, if they exist.
>   (Possibly as an option off by default, if people would prefer that)
> 
>   This would be a great improvement for users who keep source-directory
>   around (since now Emacs jumps straight to your source repo, allowing
>   easy modifications, and also you can skip installing Lisp source files
>   with Emacs) and status quo for users that don't keep source-directory
>   around.
> 
> Thoughts?
> 
> I'm interested in implementing one of these two options, since I want to
> be able to reliably jump to function definitions from an installed
> Emacs.  I don't care which of the two we go with.

Why would the Lisp sources not be available where Emacs installs them,
i.e. in the /usr/share tree?

Re: source-directory, installed Emacs, and C source

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: sbaugh@catern.com
>> Date: Tue, 24 Oct 2023 10:31:49 -0400
>> 
>> - Jumping to a newer function definition is not a problem.
>> 
>>   So we can do it for Lisp too.  We can do that by having Emacs jump to
>>   Lisp source files from source-directory, too, if they exist.
>>   (Possibly as an option off by default, if people would prefer that)
>> 
>>   This would be a great improvement for users who keep source-directory
>>   around (since now Emacs jumps straight to your source repo, allowing
>>   easy modifications, and also you can skip installing Lisp source files
>>   with Emacs) and status quo for users that don't keep source-directory
>>   around.
>> 
>> Thoughts?
>> 
>> I'm interested in implementing one of these two options, since I want to
>> be able to reliably jump to function definitions from an installed
>> Emacs.  I don't care which of the two we go with.
>
> Why would the Lisp sources not be available where Emacs installs them,
> i.e. in the /usr/share tree?

If the user ./configure'd Emacs to not install them because they prefer
to jump to source-directory instead.  That's what I meant by:

>This would be a great improvement for users who keep source-directory
>around (since now Emacs jumps straight to your source repo, allowing
>easy modifications, and also you can skip installing Lisp source files
>with Emacs)

Re: source-directory, installed Emacs, and C source

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Tue, 24 Oct 2023 11:13:33 -0400
> 
> > Why would the Lisp sources not be available where Emacs installs them,
> > i.e. in the /usr/share tree?
> 
> If the user ./configure'd Emacs to not install them because they prefer
> to jump to source-directory instead.  That's what I meant by:

How do you configure Emacs not to install the Lisp files?  And why?

> >This would be a great improvement for users who keep source-directory
> >around (since now Emacs jumps straight to your source repo, allowing
> >easy modifications, and also you can skip installing Lisp source files
> >with Emacs)

Emacs is supposed to be installed _with_ Lisp files.  It is important
to let users modify the Lisp files when they need.  So I'm not sure we
want to support an installation where Lisp files are not available.
There are also technical reasons: e.g., in Emacs that supports native
compilation, if the Lisp file cannot be found in the expected place,
Emacs will not JIT-compile the files natively, contrary to user
expectations.

Re: source-directory, installed Emacs, and C source

[Manuel Giraud via Emacs development discussions.]

sbaugh@catern.com writes:


[...]

> - Jumping to a newer function definition is a problem.
>
>   So we shouldn't be doing it for C.

I think it is already the case for « normal » Emacs users.  If you
install Emacs for your distribution's package, correct me if I'm wrong,
but you won't be able to jump to C definitions.  So this option is
already done for those users.

Now for « advanced » users (who install from sources), jumping to newer
C function definition might be a problem but being knowledgeable user,
he should know that this could be the case.
-- 
Manuel Giraud

Re: source-directory, installed Emacs, and C source

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> Date: Tue, 24 Oct 2023 18:00:16 +0200
> From:  Manuel Giraud via "Emacs development discussions." <emacs-devel@gnu.org>
> > - Jumping to a newer function definition is a problem.
> >
> >   So we shouldn't be doing it for C.
> 
> I think it is already the case for « normal » Emacs users.  If you
> install Emacs for your distribution's package, correct me if I'm wrong,
> but you won't be able to jump to C definitions.  So this option is
> already done for those users.
> 
> Now for « advanced » users (who install from sources), jumping to newer
> C function definition might be a problem but being knowledgeable user,
> he should know that this could be the case.

AFAIK, this is also true if the user installs the source distribution
(all distros offer that as an optional download).

Re: source-directory, installed Emacs, and C source

[sbaugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Tue, 24 Oct 2023 11:13:33 -0400
>> 
>> > Why would the Lisp sources not be available where Emacs installs them,
>> > i.e. in the /usr/share tree?
>> 
>> If the user ./configure'd Emacs to not install them because they prefer
>> to jump to source-directory instead.  That's what I meant by:
>
> How do you configure Emacs not to install the Lisp files?  And why?
>
>> >This would be a great improvement for users who keep source-directory
>> >around (since now Emacs jumps straight to your source repo, allowing
>> >easy modifications, and also you can skip installing Lisp source files
>> >with Emacs)
>
> Emacs is supposed to be installed _with_ Lisp files.  It is important
> to let users modify the Lisp files when they need.  So I'm not sure we
> want to support an installation where Lisp files are not available.

Yes, to be clear, I'm talking about a case where the Lisp files are in
source-directory, not where they don't exist at all.  If the Lisp files
are in source-directory and stay around there, then perhaps they don't
need to be copied to /usr/share.

But if we want to always copy them to /usr/share, that's fine, it's not
necessary to support skipping that.

My suggestion, then, is that we should allow customizing Emacs to prefer
jumping to source-directory over jumping to the installed copies of the
Lisp files.

Re: source-directory, installed Emacs, and C source

[Manuel Giraud via Emacs development discussions.]

sbaugh@catern.com writes:

[...]

> - Jumping to a newer function definition is not a problem.
>
>   So we can do it for Lisp too.  We can do that by having Emacs jump to
>   Lisp source files from source-directory, too, if they exist.
>   (Possibly as an option off by default, if people would prefer that)

Reflecting, this one may be a good idea (but behind an option I think).
An "install-from-source" user could then jump directly into
source-directory for lisp files... knowing that it may not be what he's
running.
-- 
Manuel Giraud

Re: source-directory, installed Emacs, and C source

[Emanuel Berg]

Manuel Giraud via "Emacs development discussions." wrote:

>> - Jumping to a newer function definition is a problem.
>>
>>   So we shouldn't be doing it for C.
>
> I think it is already the case for « normal » Emacs users.
> If you install Emacs for your distribution's package,
> correct me if I'm wrong, but you won't be able to jump to
> C definitions. So this option is already done for
> those users.

Not entirely, remember, one can first do the repository
package, then

  $ apt-get -qq source PACK

If you only use the repos version, and don't really care about
compiling Emacs (but you do care about the C of Emacs) -
I mean, I'm glad we have all kinds, so then yes they can use
that command to get the source corresponding to their
repository install.

-- 
underground experts united
https://dataswamp.org/~incal

Re: source-directory, installed Emacs, and C source

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Tue, 24 Oct 2023 12:20:56 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >
> > Emacs is supposed to be installed _with_ Lisp files.  It is important
> > to let users modify the Lisp files when they need.  So I'm not sure we
> > want to support an installation where Lisp files are not available.
> 
> Yes, to be clear, I'm talking about a case where the Lisp files are in
> source-directory, not where they don't exist at all.  If the Lisp files
> are in source-directory and stay around there, then perhaps they don't
> need to be copied to /usr/share.
> 
> But if we want to always copy them to /usr/share, that's fine, it's not
> necessary to support skipping that.
> 
> My suggestion, then, is that we should allow customizing Emacs to prefer
> jumping to source-directory over jumping to the installed copies of the
> Lisp files.

AFAIR, Emacs looks for Lisp files by scanning load-path.  So if you
customize load-path to include the directories in the source tree, you
should be able to tell Emacs to look for the Lisp files in another
directory.  I think that's what we do when Emacs is run uninstalled,
and that's why it finds the Lisp files in the source tree.

Re: source-directory, installed Emacs, and C source

[Emanuel Berg]

sbaugh wrote:

> Yes, to be clear, I'm talking about a case where the Lisp
> files are in source-directory, not where they don't exist at
> all. If the Lisp files are in source-directory and stay
> around there, then perhaps they don't need to be copied to
> /usr/share.

It is a sudo, system-wide installation. So those are the files
you want, that everyone wants, so it is all good. If you have
some other files anywhere else, when you install from them,
they are left behind at that moment, meaningless, unless you
want to install from them again, perhaps.

-- 
underground experts united
https://dataswamp.org/~incal

Re: source-directory, installed Emacs, and C source

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

Hi,

Manuel Giraud via "Emacs development discussions." <emacs-devel@gnu.org> writes:

> sbaugh@catern.com writes:
>
>
> [...]
>
>> - Jumping to a newer function definition is a problem.
>>
>>   So we shouldn't be doing it for C.
>
> I think it is already the case for « normal » Emacs users.  If you
> install Emacs for your distribution's package, correct me if I'm wrong,
> but you won't be able to jump to C definitions.  So this option is
> already done for those users.

This works on Gentoo with FEATURES=installsources.  We have support
code for that in the ebuild.

> Now for « advanced » users (who install from sources), jumping to newer
> C function definition might be a problem but being knowledgeable user,
> he should know that this could be the case.


-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: source-directory, installed Emacs, and C source

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> AFAIR, Emacs looks for Lisp files by scanning load-path.  So if you
> customize load-path to include the directories in the source tree, you
> should be able to tell Emacs to look for the Lisp files in another
> directory.  I think that's what we do when Emacs is run uninstalled,
> and that's why it finds the Lisp files in the source tree.

This works… but not always.  Here is a test I've just done:

     - emacs -Q
     - then load the following:
--8<---------------cut here---------------start------------->8---
(add-to-list 'load-path "~/emacs-repo/lisp/")
(dolist (dir '("vc" "use-package" "url" "textmodes" "progmodes"
	       "play" "org" "nxml" "net" "mh-e" "mail" "leim"
	       "language" "international" "image" "gnus" "eshell"
	       "erc" "emulation" "emacs-lisp" "cedet" "calendar"
	       "calc" "obsolete"))
  (add-to-list 'load-path (format "~/emacs-repo/lisp/%s/" dir)))
--8<---------------cut here---------------end--------------->8---

Now my `load-path' value is:
("~/emacs-repo/lisp/obsolete/" "~/emacs-repo/lisp/calc/"
 "~/emacs-repo/lisp/calendar/" "~/emacs-repo/lisp/cedet/"
 "~/emacs-repo/lisp/emacs-lisp/" "~/emacs-repo/lisp/emulation/"
 "~/emacs-repo/lisp/erc/" "~/emacs-repo/lisp/eshell/"
 "~/emacs-repo/lisp/gnus/" "~/emacs-repo/lisp/image/"
 "~/emacs-repo/lisp/international/" "~/emacs-repo/lisp/language/"
 "~/emacs-repo/lisp/leim/" "~/emacs-repo/lisp/mail/"
 "~/emacs-repo/lisp/mh-e/" "~/emacs-repo/lisp/net/"
 "~/emacs-repo/lisp/nxml/" "~/emacs-repo/lisp/org/"
 "~/emacs-repo/lisp/play/" "~/emacs-repo/lisp/progmodes/"
 "~/emacs-repo/lisp/textmodes/" "~/emacs-repo/lisp/url/"
 "~/emacs-repo/lisp/use-package/" "~/emacs-repo/lisp/vc/"
 "~/emacs-repo/lisp/" "/home/manuel/emacs/share/emacs/30.0.50/lisp"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/vc"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/use-package"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/url"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/textmodes"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/progmodes"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/play"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/org"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/nxml"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/net"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/mh-e"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/mail"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/leim"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/language"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/international"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/image"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/gnus"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/eshell"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/erc"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/emulation"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/emacs-lisp"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/cedet"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/calendar"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/calc"
 "/home/manuel/emacs/share/emacs/30.0.50/lisp/obsolete")

Now if I try to 'C-h f (describe-function)', some functions will point
to the source in "~/emacs-repo/" and others will point to the install
path source in "~/emacs/share/emacs/30.0.50/".  For instance:

   - 'gnus', 'eshell' and 'dired' --> ~/emacs-repo/
   - 'find-file', 'balance-windows' and 'set-frame-font' --> ~/emacs/share/emacs/30.0.50/
-- 
Manuel Giraud

Re: source-directory, installed Emacs, and C source

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: sbaugh@catern.com,  emacs-devel@gnu.org
> Date: Wed, 25 Oct 2023 10:41:33 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> [...]
> 
> > AFAIR, Emacs looks for Lisp files by scanning load-path.  So if you
> > customize load-path to include the directories in the source tree, you
> > should be able to tell Emacs to look for the Lisp files in another
> > directory.  I think that's what we do when Emacs is run uninstalled,
> > and that's why it finds the Lisp files in the source tree.
> 
> This works… but not always.  Here is a test I've just done:
> 
>      - emacs -Q
>      - then load the following:
> --8<---------------cut here---------------start------------->8---
> (add-to-list 'load-path "~/emacs-repo/lisp/")
> (dolist (dir '("vc" "use-package" "url" "textmodes" "progmodes"
> 	       "play" "org" "nxml" "net" "mh-e" "mail" "leim"
> 	       "language" "international" "image" "gnus" "eshell"
> 	       "erc" "emulation" "emacs-lisp" "cedet" "calendar"
> 	       "calc" "obsolete"))
>   (add-to-list 'load-path (format "~/emacs-repo/lisp/%s/" dir)))
> --8<---------------cut here---------------end--------------->8---

I never said you should just prepend the source tree to the previous
value, did I?

And anyway, are you sure you emulated Spencer's use case closely
enough?  He never described in detail which files are where, but AFAIU
at the very least you should have removed the *.el and *.el.gz files
from the installation directory, since that is what he does (again,
AFAIU).

Re: source-directory, installed Emacs, and C source

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: sbaugh@catern.com,  emacs-devel@gnu.org
>> Date: Wed, 25 Oct 2023 10:41:33 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> [...]
>> 
>> > AFAIR, Emacs looks for Lisp files by scanning load-path.  So if you
>> > customize load-path to include the directories in the source tree, you
>> > should be able to tell Emacs to look for the Lisp files in another
>> > directory.  I think that's what we do when Emacs is run uninstalled,
>> > and that's why it finds the Lisp files in the source tree.
>> 
>> This works… but not always.  Here is a test I've just done:
>> 
>>      - emacs -Q
>>      - then load the following:
>> --8<---------------cut here---------------start------------->8---
>> (add-to-list 'load-path "~/emacs-repo/lisp/")
>> (dolist (dir '("vc" "use-package" "url" "textmodes" "progmodes"
>> 	       "play" "org" "nxml" "net" "mh-e" "mail" "leim"
>> 	       "language" "international" "image" "gnus" "eshell"
>> 	       "erc" "emulation" "emacs-lisp" "cedet" "calendar"
>> 	       "calc" "obsolete"))
>>   (add-to-list 'load-path (format "~/emacs-repo/lisp/%s/" dir)))
>> --8<---------------cut here---------------end--------------->8---
>
> I never said you should just prepend the source tree to the previous
> value, did I?

No you did not say that.  But then what recipe with 'load-path' did you
have in mind to always look into the source tree?

> And anyway, are you sure you emulated Spencer's use case closely
> enough?  He never described in detail which files are where, but AFAIU
> at the very least you should have removed the *.el and *.el.gz files
> from the installation directory, since that is what he does (again,
> AFAIU).

Maybe this is what he does.  But then it is not what I imagined:
personally, I don't want to remove files from the installation
directory.
-- 
Manuel Giraud

Re: source-directory, installed Emacs, and C source

[sbaugh]

Manuel Giraud via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>>> Cc: sbaugh@catern.com,  emacs-devel@gnu.org
>>> Date: Wed, 25 Oct 2023 10:41:33 +0200
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> [...]
>>> 
>>> > AFAIR, Emacs looks for Lisp files by scanning load-path.  So if you
>>> > customize load-path to include the directories in the source tree, you
>>> > should be able to tell Emacs to look for the Lisp files in another
>>> > directory.  I think that's what we do when Emacs is run uninstalled,
>>> > and that's why it finds the Lisp files in the source tree.
>>> 
>>> This works… but not always.  Here is a test I've just done:
>>> 
>>>      - emacs -Q
>>>      - then load the following:
>>> --8<---------------cut here---------------start------------->8---
>>> (add-to-list 'load-path "~/emacs-repo/lisp/")
>>> (dolist (dir '("vc" "use-package" "url" "textmodes" "progmodes"
>>> 	       "play" "org" "nxml" "net" "mh-e" "mail" "leim"
>>> 	       "language" "international" "image" "gnus" "eshell"
>>> 	       "erc" "emulation" "emacs-lisp" "cedet" "calendar"
>>> 	       "calc" "obsolete"))
>>>   (add-to-list 'load-path (format "~/emacs-repo/lisp/%s/" dir)))
>>> --8<---------------cut here---------------end--------------->8---
>>
>> I never said you should just prepend the source tree to the previous
>> value, did I?
>
> No you did not say that.  But then what recipe with 'load-path' did you
> have in mind to always look into the source tree?
>
>> And anyway, are you sure you emulated Spencer's use case closely
>> enough?  He never described in detail which files are where, but AFAIU
>> at the very least you should have removed the *.el and *.el.gz files
>> from the installation directory, since that is what he does (again,
>> AFAIU).
>
> Maybe this is what he does.  But then it is not what I imagined:
> personally, I don't want to remove files from the installation
> directory.

That is not what I do.  As I said, what I'm looking for is:

> My suggestion, then, is that we should allow customizing Emacs to
> prefer jumping to source-directory over jumping to the installed
> copies of the Lisp files.

e.g. the installed copies of the Lisp files still exist, they just
aren't opened when jumping to the definitions.

Re: source-directory, installed Emacs, and C source

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Wed, 25 Oct 2023 09:43:31 -0400
> 
> > My suggestion, then, is that we should allow customizing Emacs to
> > prefer jumping to source-directory over jumping to the installed
> > copies of the Lisp files.
> 
> e.g. the installed copies of the Lisp files still exist, they just
> aren't opened when jumping to the definitions.

Why not?

Re: source-directory, installed Emacs, and C source

[sbaugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: sbaugh@catern.com
>> Date: Wed, 25 Oct 2023 09:43:31 -0400
>> 
>> > My suggestion, then, is that we should allow customizing Emacs to
>> > prefer jumping to source-directory over jumping to the installed
>> > copies of the Lisp files.
>> 
>> e.g. the installed copies of the Lisp files still exist, they just
>> aren't opened when jumping to the definitions.
>
> Why not?

Because the files in source-directory are opened instead, because that
matches the behavior with C files, and perhaps some users would like
consistency.

Re: source-directory, installed Emacs, and C source

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Wed, 25 Oct 2023 10:29:18 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> From: sbaugh@catern.com
> >> Date: Wed, 25 Oct 2023 09:43:31 -0400
> >> 
> >> > My suggestion, then, is that we should allow customizing Emacs to
> >> > prefer jumping to source-directory over jumping to the installed
> >> > copies of the Lisp files.
> >> 
> >> e.g. the installed copies of the Lisp files still exist, they just
> >> aren't opened when jumping to the definitions.
> >
> > Why not?
> 
> Because the files in source-directory are opened instead, because that
> matches the behavior with C files, and perhaps some users would like
> consistency.

There's no such "consistency" in Emacs.  The "consistency" we support
is that the Lisp files are expected to be in the installed tree.  If
they are there, I see no reason to look for them in any other
directory, and you didn't provide any real reason.  I originally
thought that you want to remove the *.el files from the installation
tree, but now I understand you don't, and I'm therefore completely
baffled about the your feature request.

Re: source-directory, installed Emacs, and C source

[Emanuel Berg]

sbaugh wrote:

> Because the files in source-directory are opened instead,
> because that matches the behavior with C files, and perhaps
> some users would like consistency.

But those Elisp files are not operational anymore, the
installed ones are. So it is to them one will want to go to
know about some Elisp function or so from a runtime Emacs (say
from the help, most often).

The C files are just present in one place so for them, that is
where you go.

It isn't consistent but also not inconsistent, it is the best
two options for two languages, and they are different because
the languages are different, not the least in the way they
are used.

-- 
underground experts united
https://dataswamp.org/~incal

Re: source-directory, installed Emacs, and C source

[chad]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

I don't run under macOS any more, but when I did, there was an extra
wrinkle here: emacs typically builds as an "app bundle", essentially a
directory named "Emacs.app" that contains all of the stuff that a typical
unix-like installation would put in various subdirs of /usr/local. This was
actually quite nice -- it meant that I could have a complete, functional
version of emacs in both Emacs.app and Emacs-old.app whenever I wanted to
try something new without stranding myself if the new thing turned out to
be broken.

I gather that more libre distributions are attempting something
functionally similar via things like Snap and Flatpak, but I don't have
much experience with either. I bring it up here because it's likely to add
an extra wrinkle to finding source files under macOS, especially if the OS
still comes with a (quite old, tty-only) version of emacs in /usr/local
that should be ignored (MAYBE: except for site-lisp?) by modern emacs.

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 1104 bytes --]

Re: source-directory, installed Emacs, and C source

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> There's no such "consistency" in Emacs.  The "consistency" we support
> is that the Lisp files are expected to be in the installed tree.  If
> they are there, I see no reason to look for them in any other
> directory, and you didn't provide any real reason.  I originally
> thought that you want to remove the *.el files from the installation
> tree, but now I understand you don't, and I'm therefore completely
> baffled about the your feature request.

I think I may have a use case: if you are working *on* Emacs
development.  I kind of know when my current running Emacs is in sync
with its source directory.  So if I want to work on some feature it is
easier to jump directly files into the source directory and start
modifying those files.  This way those modifications are directly
tracked by git in preparation of a future patch.

But maybe I'm just doing it wrong.
-- 
Manuel Giraud

Re: source-directory, installed Emacs, and C source

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Wed, 25 Oct 2023 13:43:01 -0400
> Cc: emacs-devel@gnu.org
> 
> I don't run under macOS any more, but when I did, there was an extra wrinkle here: emacs typically
> builds as an "app bundle", essentially a directory named "Emacs.app" that contains all of the stuff
> that a typical unix-like installation would put in various subdirs of /usr/local. This was actually quite
> nice -- it meant that I could have a complete, functional version of emacs in both Emacs.app and
> Emacs-old.app whenever I wanted to try something new without stranding myself if the new thing
> turned out to be broken.

??? The "Unix-like" installation puts these files in version-specific
directories, so you can have several Emacs versions available on the
same system at the same time.  I do that all the time, and have about
a dozen Emacs versions installed and runnable.

Re: source-directory, installed Emacs, and C source

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: sbaugh@catern.com,  emacs-devel@gnu.org
> Date: Wed, 25 Oct 2023 20:12:02 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> [...]
> 
> > There's no such "consistency" in Emacs.  The "consistency" we support
> > is that the Lisp files are expected to be in the installed tree.  If
> > they are there, I see no reason to look for them in any other
> > directory, and you didn't provide any real reason.  I originally
> > thought that you want to remove the *.el files from the installation
> > tree, but now I understand you don't, and I'm therefore completely
> > baffled about the your feature request.
> 
> I think I may have a use case: if you are working *on* Emacs
> development.  I kind of know when my current running Emacs is in sync
> with its source directory.  So if I want to work on some feature it is
> easier to jump directly files into the source directory and start
> modifying those files.  This way those modifications are directly
> tracked by git in preparation of a future patch.

If you are working on developing Emacs, why do you install the
development version?  The usual paradigm in that case is to run Emacs
from the source tree, uninstalled.  This is supported since about
forever.

Re: source-directory, installed Emacs, and C source

[Manuel Giraud via Emacs development discussions.]

chad <yandros@gmail.com> writes:

[...]

> I gather that more libre distributions are attempting something
> functionally similar via things like Snap and Flatpak, but I don't have
> much experience with either. I bring it up here because it's likely to add
> an extra wrinkle to finding source files under macOS, especially if the OS
> still comes with a (quite old, tty-only) version of emacs in /usr/local
> that should be ignored (MAYBE: except for site-lisp?) by modern emacs.

I don't really know how it works on macOS but I think that in this case
Emacs was able to find its installation files into the Emacs.app
directory.  Of course, /usr/local should not be considered as place to
find source files here.
-- 
Manuel Giraud

Re: source-directory, installed Emacs, and C source

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

>> I think I may have a use case: if you are working *on* Emacs
>> development.  I kind of know when my current running Emacs is in sync
>> with its source directory.  So if I want to work on some feature it is
>> easier to jump directly files into the source directory and start
>> modifying those files.  This way those modifications are directly
>> tracked by git in preparation of a future patch.
>
> If you are working on developing Emacs, why do you install the
> development version?  The usual paradigm in that case is to run Emacs
> from the source tree, uninstalled.  This is supported since about
> forever.

But, as I said, I could be doing it wrong ;-) Thanks for enlightening
me.  I will look into how to run Emacs uninstalled.
-- 
Manuel Giraud

Re: source-directory, installed Emacs, and C source

[chad]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

On Wed, Oct 25, 2023 at 2:32 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: chad <yandros@gmail.com>
> > Date: Wed, 25 Oct 2023 13:43:01 -0400
> > Cc: emacs-devel@gnu.org
> >
> > I don't run under macOS any more, but when I did, there was an extra
> wrinkle here: emacs typically
> > builds as an "app bundle", essentially a directory named "Emacs.app"
> that contains all of the stuff
> > that a typical unix-like installation would put in various subdirs of
> /usr/local. This was actually quite
> > nice -- it meant that I could have a complete, functional version of
> emacs in both Emacs.app and
> > Emacs-old.app whenever I wanted to try something new without stranding
> myself if the new thing
> > turned out to be broken.
>
> ??? The "Unix-like" installation puts these files in version-specific
> directories, so you can have several Emacs versions available on the
> same system at the same time.  I do that all the time, and have about
> a dozen Emacs versions installed and runnable.
>

This works if the versions have distinct version numbers, which was not
always the case in my experience back then. This was especially relevant
when testing alternative ports, such as ns versus carbon, different
toolkits,
and when hunting bugs or testing features that required a longer run-time
to exercise. This Emacs.app approach applied to building from HEAD as
well (my primary use case for many years).

The key thing I was trying to convey is just this: a commonly used platform
keeps all of these relevant files in a non-shared, non-central,
non-source-tree
hierarchy, then arranges on startup to find these directories and set
appropriate
elisp vars to DTRT. If one wants to change the process of finding sources
in
emacs, and one wants to support macOS, one should expect a little extra
effort needed on that platform.

~Chad

[-- Attachment #2: Type: text/html, Size: 2559 bytes --]

Re: source-directory, installed Emacs, and C source

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Wed, 25 Oct 2023 16:30:01 -0400
> Cc: sbaugh@catern.com, emacs-devel@gnu.org
> 
>  ??? The "Unix-like" installation puts these files in version-specific
>  directories, so you can have several Emacs versions available on the
>  same system at the same time.  I do that all the time, and have about
>  a dozen Emacs versions installed and runnable.
> 
> This works if the versions have distinct version numbers, which was not
> always the case in my experience back then.

Changing the version of Emacs for your local purposes is a very simple
procedure, a matter of running a Lisp function in admin.el and then
rebuilding.  If you need to have multiple XX.YY versions of Emacs
installed with the same XX.YY, just set the version to be XX.YY.zz,
with zz chosen by you, and then rebuild and install.  It's very simple.

> This was especially relevant
> when testing alternative ports, such as ns versus carbon, different toolkits,
> and when hunting bugs or testing features that required a longer run-time
> to exercise.

Files produced by the build that are architecture-dependent are
installed in architecture-specific subdirectories or /usr/local, so
you can have several Emacs versions on the same machine compiled for
different architectures, let alone different configurations.

> The key thing I was trying to convey is just this: a commonly used platform
> keeps all of these relevant files in a non-shared, non-central, non-source-tree
> hierarchy, then arranges on startup to find these directories and set appropriate
> elisp vars to DTRT. If one wants to change the process of finding sources in 
> emacs, and one wants to support macOS, one should expect a little extra
> effort needed on that platform.

I don't think we need to learn anything from macOS in this area.  Our
current installation system solves these issues in a different manner,
but it does solve them, and the solutions are simple, easy to
understand, and easy to use (unlike macOS solutions that are so
obscure and complex that even macOS users here don't really understand
all their quirks).