GNU bug report logs - #1333
23.0; Emacs.app does not load ~/.emacs

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1333 in the body.
You can then email your comments to 1333 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.0; Emacs.app does not load ~/.emacs
Date: Wed, 12 Nov 2008 16:54:29 +0200

Package: emacs,ns

On GNUstep, Emacs.app does not load the user init file.

Probably related, but it also doesn't inherit the environment when run
from a terminal; the value of process-environment right after startup
is "TERM=dumb".  Doing M-x ns-grabenv doesn't help much:

process-environment's value is 
("_=/usr/bin/printenv" "SHLVL=1" "PWD=/home/yavor/src/emacs/src" "TERM=dumb")

(This is when started with -nw, the only difference otherwise is the
confusing "DISPLAY=keel.southway-varna.com".)

`printenv | wc -l' returns 29.

If Emacs was built in a chroot and installed in a system-wide
location, e.g. /usr/lib/GNUstep/System/Applications, then M-x gnus
tries to create /News at the root of the filesystem.  Many commands do
not work, and Emacs becomes useful only after manually setting some
variables with M-x setenv and loading .emacs.

(P.S.: The `23.0;' in the subject line is the figure exactly as
generated by M-x report-emacs-bug.)

In GNU Emacs 23.0.60 (i686-pc-linux-gnu, NS gnustep-gui-0.14.0)
 of 2008-11-12 on keel.southway-varna.com
Windowing system distributor `GNU', version 103.110.117.115.116.101.112.45.103.117.105.45.48.46.49.52.46.48
configured using `configure  '--with-ns' '--disable-ns-self-contained' '--prefix=/home/yavor/tmp''

Message #10 received at 1333 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 1333 <at> debbugs.gnu.org
Cc: Yavor Doganov <yavor <at> gnu.org>
Subject: #1333 - 23.0; Emacs.app does not load ~/.emacs - Emacs bug report logs
Date: Fri, 21 Nov 2008 15:43:10 -0500

Hi,

I have never seen this before, though the last time I ran GNUstep- 
emacs was a couple of years ago.  Still, I would think not  
loading .emacs and trashing the env would be bugs that would be  
noticed that quickly.  The only thing I could possibly imagine this  
relating to is some recent change in the CANNOT_DUMP pathway.

Message #15 received at 1333 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 1333 <at> debbugs.gnu.org
Cc: Yavor Doganov <yavor <at> gnu.org>
Subject: Re: 23.0; Emacs.app does not load ~/.emacs
Date: Fri, 6 Mar 2009 21:39:24 +0200

Hi,

Does this bug still exist?

thanks,
Adrian

Message #20 received at 1333 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 1333 <at> debbugs.gnu.org, Yavor Doganov <yavor <at> gnu.org>
Subject: Re: 23.0; Emacs.app does not load ~/.emacs
Date: Fri, 06 Mar 2009 23:19:24 +0200

Adrian Robert wrote:
> Does this bug still exist?

Yes, unfortunately.

GNU Emacs 23.0.91 (i686-pc-linux-gnu, NS gnustep-gui-0.12.0) of
2009-03-06 on gana.yavor.doganov.org

You wrote some time ago (21 Nov 2008):

> Still, I would think not loading .emacs and trashing the env would
> be bugs that would be noticed that quickly.

I don't think so.  How many people you think build and run the GNUstep
port?  I tried Emacs.app before the merge two or three times, and it
was crashing immediately or drawing and expaniding the frame
horizontally && crashing all the time (basically what it does now
under GNOME with certain configurations, and with the GNUstep cairo
backend).  So I decided to wait until unicode-2 gets merged in Emacs
trunk, and Emacs.app after that.  I believe you that it worked before
the merge, and probably after the merge.  But the code changed
significantly after that.

I deliberately did not report the absolutely trivial problem in #2264;
it took about two months after someone reported it here and about 3
months after a prominent GNUstep user and maintainer reported in on a
GNUstep mailing list.  I know that this strategy is very bad, since
only a very small percentage of the users report bugs.  Anyway, my
point still holds, I think.  The only port that has less users is the
MS-DOG port.

So, in conclusion, very few people are trying to build, *run*, and
*use* the GNUstep port.  This should not be surprising to anyone.

I have identified some changes that look suspicious for this problem
(after the merge), but reverting them just either brings my machines
down when compiling Emacs, or does not fix the problem at all.

In general, I think that 99% of the problems for the GNUstep port are
due to CANNOT_DUMP.  Is there any other platform/system/whatever where
CANNOT_DUMP works (i.e. where it leads to an usable Emacs)?  My
general feeling is that this is the first port that is supposed to be
used in production, and the CANNOT_DUMP limitations simply cannot
provide that.

Message #25 received at 1333 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Yavor Doganov <yavor <at> gnu.org>
Cc: 1333 <at> debbugs.gnu.org
Subject: Re: 23.0; Emacs.app does not load ~/.emacs
Date: Sat, 7 Mar 2009 00:03:48 +0200

On Mar 6, 2009, at 11:19 PM, Yavor Doganov wrote:

> In general, I think that 99% of the problems for the GNUstep port are
> due to CANNOT_DUMP.  Is there any other platform/system/whatever where
> CANNOT_DUMP works (i.e. where it leads to an usable Emacs)?  My
> general feeling is that this is the first port that is supposed to be
> used in production, and the CANNOT_DUMP limitations simply cannot
> provide that.

As I posted earlier on emacs-devel, fixing CANNOT_DUMP might be as  
simple as adding similar zone alloc commands to unexelf.c as in  
unexmacosx.c.  (I wish I'd noticed this when I was working on  
GNUstep.)  It might be possible to use unexnext as a simpler model  
(kept around until shortly after the merge).  I haven't tried it  
myself due to no longer having access to a GNUstep compile  
environment and already having my hands full with OS X bugs.  But if  
you or someone else wants to take a crack, I can provide assistance  
over email.

I agree with you about the low number of users.  I think if Gurkan  
can (heroically) manage get the package in to Debian it will expand  
the user base, and hopefully at least slightly improve the number  
actually rolling up their sleeves and trying to fix things.


-Adrian

Message #30 received at 1333 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: Yavor Doganov <yavor <at> gnu.org>, 1333 <at> debbugs.gnu.org
Subject: Re: 23.0; Emacs.app does not load ~/.emacs
Date: Sat, 07 Mar 2009 02:58:21 +0200

Adrian Robert wrote:
> As I posted earlier on emacs-devel, fixing CANNOT_DUMP might be as  
> simple 

I will reply to that (very informative and useful) post when I feel I
have the guts to, but:

> as adding similar zone alloc commands to unexelf.c as in  
> unexmacosx.c.

That's not possible, AFAICT.  The GNU C library has no knowledge of
zones, so it is not possible to copy the logic from unexmacosx.c to
unexelf.c just like that.

> It might be possible to use unexnext as a simpler model (kept around
> until shortly after the merge).

I don't know anything about unexnext.  I guess I can dig it out from
the SF repo; thanks for the pointer.

One possible way to solve the problem is to use NSZone functions
wrapped and callable from C.  But unexmacosx.c does some low-level
things which are not possible with NSZone.  So it is doubtful if this
approach would succeed at all.

> I think if Gurkan can (heroically) manage get the package in to
> Debian 

It doesn't depend on him, it is the Debian Emacs maintainers' call.

> it will expand the user base, and hopefully at least slightly
> improve the number actually rolling up their sleeves and trying to
> fix things.

Yes, I absolutely agree that it is up to us (GNUstep users) to solve
these problems.  But the CANNOT_DUMP problem is not a "simple problem"
so one should not expect that a mortal user can solve such a major
issue somehow, somewhen.

Message #35 received at 1333 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yavor Doganov <yavor <at> gnu.org>, 1333 <at> debbugs.gnu.org
Cc: adrian.b.robert <at> gmail.com
Subject: Re: bug#1333: 23.0; Emacs.app does not load ~/.emacs
Date: Sat, 07 Mar 2009 10:22:18 +0200

> From: Yavor Doganov <yavor <at> gnu.org>
> Cc: Yavor Doganov <yavor <at> gnu.org>, 1333 <at> emacsbugs.donarmstrong.com
> 
> The only port that has less users is the MS-DOG port.

I suppose you have statistics to back up this assertion?

Message #40 received at 1333 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Yavor Doganov <yavor <at> gnu.org>, 1333 <at> debbugs.gnu.org,
        adrian.b.robert <at> gmail.com
Subject: Re: bug#1333: 23.0; Emacs.app does not load ~/.emacs
Date: Sun, 08 Mar 2009 15:41:42 +0200

Eli Zaretskii wrote:
> > The only port that has less users is the MS-DOG port.
> 
> I suppose you have statistics to back up this assertion?

No, it was just a guess.  On second thought, it might be a false
assertion.  It is possible that the MS-DOS port has more users than
the GNUstep port.

Message #45 received at 1333-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: 1333-done <at> debbugs.gnu.org
Subject: Finally fixed
Date: Mon, 22 Jun 2009 23:42:19 +0300

This bug was fixed now that the GNUstep port "CAN_DUMP"; Emacs loads
the init file as well as all the environment variables.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.