From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Felix Mueller Newsgroups: gmane.emacs.devel Subject: Re: NS do not set INFOPATH Date: Sun, 31 May 2009 10:49:10 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1243759796 15768 80.91.229.12 (31 May 2009 08:49:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 May 2009 08:49:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 31 10:49:52 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MAgjl-00058N-TG for ged-emacs-devel@m.gmane.org; Sun, 31 May 2009 10:49:50 +0200 Original-Received: from localhost ([127.0.0.1]:41693 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAgjl-00020c-Ai for ged-emacs-devel@m.gmane.org; Sun, 31 May 2009 04:49:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MAgjf-00020P-57 for emacs-devel@gnu.org; Sun, 31 May 2009 04:49:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MAgjY-0001zp-Qd for emacs-devel@gnu.org; Sun, 31 May 2009 04:49:41 -0400 Original-Received: from [199.232.76.173] (port=40142 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAgjY-0001zm-KR for emacs-devel@gnu.org; Sun, 31 May 2009 04:49:36 -0400 Original-Received: from www151.your-server.de ([213.133.104.151]:53707) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MAgjY-0007Mh-6T for emacs-devel@gnu.org; Sun, 31 May 2009 04:49:36 -0400 Original-Received: from [213.73.117.113] (helo=ereboook.local) by www151.your-server.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MAgjE-0006ut-Po for emacs-devel@gnu.org; Sun, 31 May 2009 10:49:18 +0200 In-Reply-To: (Adrian Robert's message of "Sat, 16 May 2009 23:26:38 +0000 (UTC)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (darwin) X-Authenticated-Sender: felix@enqueue.eu X-Virus-Scanned: Clear (ClamAV 0.95.1/9407/Sat May 30 19:37:30 2009) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:111211 Archived-At: Hi, * Adrian Robert -- [2009-05-17] writes: > Felix Mueller enqueue.eu> writes: > >> an easier alternative would be to simply add a colon to resourcePath >> in nsterm.m (~ line 418). This way, contents of INFOPATH and >> Info-default-directory-list are merged when invoking info. > > I'm less familiar with this area than you, but it seems strange that > emacs expects a user env setting for INFOPATH to have a path-separator > already appended to it. Shouldn't the code that as you say merges > INFOPATH and Info-default-directory-list take care of this? I think, this is a deliberate choice (see texinfo manual): either merge or overwrite. >> I would typically not expect most of the programs I use to set an >> environment variable by themselves, and I spent a couple of minutes >> figuring out what was happening and checking for other places that >> might be responsible for the INFOPATH environment variable. That's why >> I wrote the email > > So it seems the problem is not with INFOPATH per se, but the whole > approach used by ns-init-paths. Would it be possible to use the > alternative you posted for all of these other variables as well, or > would they be adjusted too late? I tried looking into this, but I am simply not familiar enough with Emacs' startup. It seems to me, that this mechanism would not work without additional, heavier changes to nsterm.m, unless you are ruling out users moving their application bundle (bad idea, in my opinion). While I do consider setting paths within a program via environment variables "unexpected", the other variables have not been problematic for me, so far. As far as I can tell, w32 uses a similar approach (w32.c init_environment), and only excludes INFOPATH. Thanks! -- Felix Mueller felix@enqueue.eu