Path: utzoo!attcan!uunet!lll-winken!ames!xanth!ukma!tut.cis.ohio-state.edu!bloom-beacon!THINK.COM!rlk
From: rlk@THINK.COM (Robert L. Krawitz)
Newsgroups: comp.windows.x
Subject: GNU Emacs shell mode and DISPLAY env variable
Message-ID: <8902011634.AA18559@fafnir.think.com>
Date: 1 Feb 89 16:34:35 GMT
References: <35443@bbn.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 58


   Date: 1 Feb 89 14:56:56 GMT
   From: jr%bbn.com@bbn.com  (John Robinson)

   In article <35945@think.UUCP>, barmar@think (Barry Margolin) writes:

   If you set the DISPLAY variable coming into emacs, it will be
   inherited by the shell.  So instead of starting emacs this way:

     emacs -d unix:0

   say (to csh):

     setenv DISPLAY unix:0 ; emacs

This can be done, but in the local environment it's a pain.  Having to
bootstrap the display into emacs lisp by means of the underlying shell
isn't a very effective solution.

   Now, the variable command-line-args ought to have your "-d" and
   display-name in it, but the X code strips away its args from this list
   when it starts up.  This seems to be a bug.  I suspect it is due to
   the X code really being a graft onto emacs at this point.  Really, the
   switches should be handled in the same loop that handles the rest of
   the switches to emacs, but it has to run sooner in order to set up the
   new X window, etc.  Maybe v19 will get this better...

The danger with handling the X switches in the same loop as the other
switches is that if the startup.el code fails, your window will never
come up.  The initial X code handled the switches in just this
fashion, but it wound up being very slow and flaky (when startup
failed).  I fixed this in X10 emacs to force processing of
switches/defaults early on, but I did all my operations on a copy of
argv and never nuked the command line switches, but rather hacked the
x init file to handle the X command line switches and ignore them
(this can, of course, be overridden by your .emacs file).  Most people
running emacs with X10 are using the "old" command line processing
rather than the "new" (the only places using the "new" processing are
Thinking Machines and Project Athena before they converted to X11).
If the X11 code is splicing out the X command line arguments, then
it's doing something wrong.

The emacs 18 X code (and emacs 17, and even emacs 16) X code was
indeed a graft onto emacs.  RMS did put in various display and startup
hooks in version 17 so that Yakim Martillo and later I could do the X
code without it being overly dirty.  The problem, though, is that
emacs treats X as being simply a terminal emulator (not in the sense
of xterm, but rather in the sense of there being a set of display
primitives that are very terminal based; the system is somewhat like
curses in the sense of having a set of primitive operations), because
emacs 18 is still terminal-based.  I have not been involved in the
development of X11/emacs (which based on a quick study of the code
appears to be a straight port of emacs/X10 without use of the
toolkit), nor have I been involved in the development of emacs 19.

harvard >>>>>>  |	Robert Krawitz <rlk@think.com>	245 First St.
bloom-beacon >  |think!rlk	(postmaster)		Cambridge, MA  02142
topaz >>>>>>>>  .	Thinking Machines Corp.		(617)876-1111