From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Correct Path to Emacs C Sources after Installation Date: Wed, 05 Nov 2014 18:53:40 +0200 Message-ID: <834mudvbaj.fsf@gnu.org> References: <83bnolvdxp.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1415206453 16070 80.91.229.3 (5 Nov 2014 16:54:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2014 16:54:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alexander Shukaev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 05 17:54:06 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xm3qO-0002ik-Vf for ged-emacs-devel@m.gmane.org; Wed, 05 Nov 2014 17:54:05 +0100 Original-Received: from localhost ([::1]:47516 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xm3qO-00040c-MM for ged-emacs-devel@m.gmane.org; Wed, 05 Nov 2014 11:54:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xm3qE-00040W-JZ for emacs-devel@gnu.org; Wed, 05 Nov 2014 11:54:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xm3q7-0002Um-2A for emacs-devel@gnu.org; Wed, 05 Nov 2014 11:53:54 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:56172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xm3q6-0002UZ-LL for emacs-devel@gnu.org; Wed, 05 Nov 2014 11:53:46 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NEK00800RXKNL00@mtaout26.012.net.il> for emacs-devel@gnu.org; Wed, 05 Nov 2014 18:52:15 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEK007ZTS73V310@mtaout26.012.net.il>; Wed, 05 Nov 2014 18:52:15 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:176413 Archived-At: > Date: Wed, 5 Nov 2014 17:23:35 +0100 > From: Alexander Shukaev > > 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.