From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.bugs Subject: bug#14513: 24.3.50; Site load-path pieces differ in MSYS build Date: Thu, 30 May 2013 18:56:10 +0100 Message-ID: References: <83y5aw4e0x.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01635502a4c5cc04ddf336f4 X-Trace: ger.gmane.org 1369936608 14777 80.91.229.3 (30 May 2013 17:56:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 May 2013 17:56:48 +0000 (UTC) Cc: 14513@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 30 19:56:48 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Ui75i-0006Pk-6B for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 May 2013 19:56:46 +0200 Original-Received: from localhost ([::1]:45247 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui75h-0000Q4-R7 for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 May 2013 13:56:45 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui75Z-0000H5-OM for bug-gnu-emacs@gnu.org; Thu, 30 May 2013 13:56:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ui75U-0001Rf-CX for bug-gnu-emacs@gnu.org; Thu, 30 May 2013 13:56:37 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui75U-0001RX-9J for bug-gnu-emacs@gnu.org; Thu, 30 May 2013 13:56:32 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Ui76w-0001Tk-7I for bug-gnu-emacs@gnu.org; Thu, 30 May 2013 13:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Richard Copley Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 30 May 2013 17:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14513 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14513-submit@debbugs.gnu.org id=B14513.13699366695662 (code B ref 14513); Thu, 30 May 2013 17:58:02 +0000 Original-Received: (at 14513) by debbugs.gnu.org; 30 May 2013 17:57:49 +0000 Original-Received: from localhost ([127.0.0.1]:42671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ui76j-0001TG-8d for submit@debbugs.gnu.org; Thu, 30 May 2013 13:57:49 -0400 Original-Received: from mail-ea0-f182.google.com ([209.85.215.182]:61429) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ui76g-0001T2-N2 for 14513@debbugs.gnu.org; Thu, 30 May 2013 13:57:48 -0400 Original-Received: by mail-ea0-f182.google.com with SMTP id r16so661221ead.13 for <14513@debbugs.gnu.org>; Thu, 30 May 2013 10:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JzcIPaA/3kuPvPEWuvFgxw2c9xk2WrTVNAwItxKfrAc=; b=txkpe3JoEi60HwrqEoTSl+rS/5p7KJmVrl63dWQgmoZTmkrV9czVMQOseG2WGkmD71 phhAxbhKF2W7CuNjUlllVynvVbrLNsaVIbv+9lKBdRCmLjhBtqFiAz43D/IBvQ+0seSf 7aYqIZBPyZH22rlPPsFptvvQpPYOEDWeSglH3TuTxVhSBBIY7RaJWZWIyS/obRiluuXU 3uwQFNuBMHUlJeJ4a6aINZLvLWKp/PNRq17Crqn7EH9dfwgOVWbqh81PSewhEY52fwDA AaSlFSQr4GMoeptknc1B+y5GA8qVxX8yGOQgafMw8LGwlSu0Xn4HQ1u/7Sy59WhSD5ez 8c5A== X-Received: by 10.15.111.202 with SMTP id cj50mr10621058eeb.140.1369936570392; Thu, 30 May 2013 10:56:10 -0700 (PDT) Original-Received: by 10.14.212.67 with HTTP; Thu, 30 May 2013 10:56:10 -0700 (PDT) In-Reply-To: <83y5aw4e0x.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:74665 Archived-At: --089e01635502a4c5cc04ddf336f4 Content-Type: text/plain; charset=ISO-8859-1 On 30 May 2013 17:40, Eli Zaretskii wrote: > > Date: Thu, 30 May 2013 14:46:13 +0100 > > From: Richard Copley > > > > The site-specific pieces of the initial load-path are different in the > > nt/msysconfig.sh build from how they used to be with nt/configure.bat. > > Indeed, and that is on purpose. I explained the rationale here: > > http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00146.html > > > In src/epaths.h (when built), PATH_SITELOADSEARCH is defined as: > > > > with nt/configure.bat: "%emacs_dir%/site-lisp;%emacs_dir%/../site-lisp" > > > > with nt/msysconfig.sh: > > > "%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp" > > > > The former version was much more useful on Windows, allowing > > one to keep a bunch of Emacs installs in a single parent directory > > that also contains the site-lisp directory. > > Sorry, I don't follow. Please describe what structure was possible > beforehand that you think is impossible now. > I'm not sure which part you're having trouble with, so I'll be quite expansive and hopefully you'll see what I mean. Perhaps this should be a reply to the emacs-devel message, but I didn't see that at the time and it's a bit late now. What used sometimes to be called NT Emacs is (or was) a portable app. When you've unpacked (or built) it, everything is inside "bin/..". Call that the "application directory". You install by moving and renaming the application directory, and uninstall by deleting. Ideally, you never modify any file inside the application directory. Putting an Emacs bin directory on the system-wide path is optional. The user can be trusted to work out how to invoke the right executable. Emacs finds the right auxiliary executables and DOC file just fine, even with the "-Q" command-line argument. I had a bunch of these application directories, my own builds of the trunk, at different revisions. Like this (but with more Emacs): c:\>dir /B c:\emacs emacs-111818 emacs-112125 emacs-112416 site-lisp This particular arrangement was suggested, to my mind anyway, by the existence of the "%emacs_dir%/../site-lisp" entry in load-path. I don't say it's impossible to do the same thing any more, just that it no longer works out of the box as it used to (unless of course I've made some other mistake). If, as you say, it's a design decision, then that's fine. I disagree but I don't object. --089e01635502a4c5cc04ddf336f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 3= 0 May 2013 17:40, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Thu, 30 May 2013 14:46:13 +0100
> From: Richard Copley <rcopley@gmail.com>
>
> The site-specific pieces of the initial load-path are different in the=
> nt/msysconfig.sh build from how they used to be with nt/configure.bat.=

Indeed, and that is on purpose. =A0I explained the rationale here:

=A0 http://lists.gnu.org/archive/html/emacs-devel/20= 13-04/msg00146.html

> In src/epaths.h (when built), PATH_SITELOADSEARCH is defined as:
>
> =A0 with nt/configure.bat: "%emacs_dir%/site-lisp;%emacs_dir%/../= site-lisp"
>
> =A0 with nt/msysconfig.sh:
> "%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emac= s/site-lisp"
>
> The former version was much more useful on Windows, allowing
> one to keep a bunch of Emacs installs in a single parent directory
> that also contains the site-lisp directory.

Sorry, I don't follow. =A0Please describe what structure was possible beforehand that you think is impossible now.

I'm not sure which part you're having t= rouble with, so I'll be quite
expansive and hopefully you'll see= what I mean. Perhaps this should be
a reply to the emacs-devel message,= but I didn't see that at the time
and it's a bit late now.

What used sometimes to be called NT Ema= cs is (or was) a portable app.
When you've unpacked (or built) it, e= verything is inside "bin/..".
Call that the "application = directory". You install by moving and
renaming the application directory, and uninstall by deleting.
Ideally, = you never modify any file inside the application directory.
Putting an E= macs bin directory on the system-wide path is optional.
The user can be = trusted to work out how to invoke the right executable.
Emacs finds the right auxiliary executables and DOC file just fine,
even= with the "-Q" command-line argument.

I had a b= unch of these application directories, my own builds of the
trunk, at di= fferent revisions. Like this (but with more Emacs):

=A0 c:\>dir /B c:\emacs
=A0 emacs-111818
=A0 emacs-112125
= =A0 emacs-112416
=A0 site-lisp

This particular arrangement was su= ggested, to my mind anyway, by
the existence of the "%emacs_dir%/..= /site-lisp" entry in load-path.

I don't say it's impossible to do the same thing any more, just= that
it no longer works out of the box as it used to (unless of course = I've
made some other mistake). If, as you say, it's a design dec= ision, then
that's fine. I disagree but I don't object.

--089e01635502a4c5cc04ddf336f4--