Re: Correct Path to Emacs C Sources after Installation

[Eli Zaretskii]

> Date: Wed, 5 Nov 2014 17:23:35 +0100
> From: Alexander Shukaev <address@hidden>
> 
>     Unless I'm missing something, this unconditionally sets the value of
>     source-directory to /usr/local/share/emacs/VERSION/etc/ in the
>     installed binary, is that right? If so, I don't think this can be
>     acceptable, because it disallows the current practice of leaving the
>     sources where Emacs was built.
> 
> It sets the default to "/usr/local/share/emacs/VERSION/" only when Emacs is
> installed.

What happens in the installed Emacs _is_ the focus in this discussion.

Like I said, I don't think it's acceptable to break the current
behavior, because some people (like myself, for example) leave the
source tree of an installed Emacs around for a very long time, in the
same place where Emacs was compiled.  We must continue supporting this
use case.  There's no reason to stop supporting it.

> So that sources would end up under "/usr/local/share/emacs/VERSION/src".

They will not be found there, unless Emacs is configured with the
(proposed) option of installing the sources.  So by disabling the
current behavior, you break an existing feature, which I don't think
is acceptable, or even justified.

>     As I said earlier, I like Stefan's suggestion of changing the users of
>     this variable, so that they could look in alternative places if the C
>     sources in source-directory are not accessible.
> 
> They can tweak it by changing this variable manually to point to those
> alternative places.

Who are "they"?  By "users" I meant here the code that uses this
variable, I didn't mean people.

What I'm saying is that instead of changing the value of
source-directory, make the functions which use it look in other places
if the file they look for is not found under source-directory.  This
way, the existing behavior is preserved, and your optional behavior
becomes possible, _if_ the sources aren't in the place where Emacs was
built.  I think this gives you the best of both worlds.

> Here we're considering only reasonable default. By the way
> this default complies with how "load-path" is initialized.

The way load-path is used and its purpose are very different.

>     After all, it might
>     well be that the sources are being removed while Emacs is running, so
>     a one-time computation might still cause failure.
>     
> 
> After all, it might be that "lisp" and "site-lisp" sources are removed too and
> then Emacs would fail too. It's not about 1 time computation here. If ones
> moves sources, then one is responsible to change the value of the variable
> manually through Emacs Lisp. Once again the discussion is about default. 
> Anyway
> what's your point here?

My point is that moving the solution to the functions that use this
variable solves your problem, and in addition (a) doesn't break
existing behavior, and (b) can support the use case where Someone(TM)
removes the source tree while SomeoneElse(TM) has an Emacs session
running on the same system.  The latter might not be a big deal, but
it's an advantage that you get for free.

>     There are only 2 users of source-directory now: find-func.el and
>     check-declare.el. All you need is to teach them to look in
>     data-directory if the files cannot be found in source-directory. I
>     think this will be much easier, and perhaps should also use some
>     defcustom that users could customize (e.g., Emacs could look in a list
>     of directories, not just one particular place).
>     
> 
> This haven't been done before, i.e. there was only a hard coded path to 
> sources
> during build and nobody cared. Why would we need to do that now and why is 
> this
> easier than the proposed patch, could you elaborate?

See above: it preserves the existing behavior, it doesn't change the
semantics of source-directory, and it solves your problem in a cleaner
way.

Put it another way: your original problem was that Emacs was unable to
show the implementation of Emacs primitives when the original source
directory was unavailable for some reason.  I say: solve that problem,
where it happens, i.e. in find-func.el, which looks for a C file to
show the function.

> You don't like C code changes?

It is true that we generally prefer to add features in Lisp rather
than in C.  But that's not the main issue in this case, at least not
IMO.