bug#1333: 23.0; Emacs.app does not load ~/.emacs

bug#1333: 23.0; Emacs.app does not load ~/.emacs

[Yavor Doganov]

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''

bug#1333: 23.0; Emacs.app does not load ~/.emacs

[Adrian Robert]

Hi,

Does this bug still exist?

thanks,
Adrian

bug#1333: 23.0; Emacs.app does not load ~/.emacs

[Yavor Doganov]

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.

bug#1333: 23.0; Emacs.app does not load ~/.emacs

[Adrian Robert]

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

bug#1333: 23.0; Emacs.app does not load ~/.emacs

[Yavor Doganov]

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.

bug#1333: 23.0; Emacs.app does not load ~/.emacs

[Eli Zaretskii]

> From: Yavor Doganov <yavor@gnu.org>
> Cc: Yavor Doganov <yavor@gnu.org>, 1333@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?

bug#1333: 23.0; Emacs.app does not load ~/.emacs

[Yavor Doganov]

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.

bug#1333: marked as done (23.0; Emacs.app does not load ~/.emacs)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]


Your message dated Mon, 22 Jun 2009 23:42:19 +0300
with message-id <87fxds6lw4.GNU's_Not_Unix!%yavor@gnu.org>
and subject line Finally fixed
has caused the Emacs bug report #1333,
regarding 23.0; Emacs.app does not load ~/.emacs
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
1333: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1333
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3781 bytes --]

From: Yavor Doganov <yavor@gnu.org>
To: bug-gnu-emacs@gnu.org
Subject: 23.0; Emacs.app does not load ~/.emacs
Date: Wed, 12 Nov 2008 16:54:29 +0200
Message-ID: <874p2df10a.GNU's_Not_Unix!%yavor@gnu.org>

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''




[-- Attachment #3: Type: message/rfc822, Size: 2266 bytes --]

From: Yavor Doganov <yavor@gnu.org>
To: 1333-done@emacsbugs.donarmstrong.com
Subject: Finally fixed
Date: Mon, 22 Jun 2009 23:42:19 +0300
Message-ID: <87fxds6lw4.GNU's_Not_Unix!%yavor@gnu.org>

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