dld@theory.cs.cmu.edu (David Detlefs) (03/19/87)
I have a little problem I was wondering if someone could help me with. I am running X, using the uwm window manager. I have modified my .uwmrc file with the intent of causing a certain button combination to cause a menu to appear with some favorite commands. I have no problem with commands like !"xterm -e telnet g &". However, when I attempt to do !"emacs &", nothing happens. However, when I eventually kill uwm, I find I have started an emacs which I am plunked into. I had been under the impression that emacs knew whether to run as an X application or not based on the setting of the DISPLAY environment variable, which I know is set at the time my login shell gets the "emacs" command. Is this impression mistaken? Does anyone have a clue about how I can get the behavior I want? Thanks! Dave
tsf@theory.cs.cmu.edu (Timothy Freeman) (03/19/87)
In article <1023@theory.cs.cmu.edu> dld@theory.cs.cmu.edu (David Detlefs) writes: >However, when I attempt to >do !"emacs &", nothing happens. However, when I eventually kill uwm, >I find I have started an emacs which I am plunked into. Here's the line I use to start Gnu-emacs from my .uwmrc: !"xterm =10x10-1000-1000 -e emacs -w =143x68+0+0&" The xterm window is positioned off the screen so I don't have to look at it. If I replace the xterm by a csh, everything works more or less the same except that emacs frequently neglects to bring the screen up to date when it should. There are a lot of unknowns here that I haven't explored, so I can't tell you much more than the fact that the above incantation seems to work best. I'm using XV10R4 from a Sun 3 running 4.2 Bsd release 3.0, if that matters. Tim Freeman Arpanet: tsf@theory.cs.cmu.edu Uucp: ...!seismo!theory.cs.cmu.edu!tsf
avolio@decuac.DEC.COM (Fred Avolio) (03/19/87)
In article <1024@theory.cs.cmu.edu>, tsf@theory.cs.cmu.edu (Timothy Freeman) writes: > In article <1023@theory.cs.cmu.edu> dld@theory.cs.cmu.edu (David Detlefs) writes: > >However, when I attempt to > >do !"emacs &", nothing happens. However, when I eventually kill uwm, > >I find I have started an emacs which I am plunked into. > > Here's the line I use to start Gnu-emacs from my .uwmrc: > > !"xterm =10x10-1000-1000 -e emacs -w =143x68+0+0&" Nahhhhhh. I use: "emacs":(White:"#0000ff"): !"emacs -font 9x15&" AT least this is okay under X on a VaxstationII running Ultrix-32. Otherwise you add an extra process or so on top ( though it does work...) To the original poster... Aside from doing it from the mouse,. can you enter the command (at the prompt) "emacs &" The behavior should be the same (window brought up, etc.). And you can try "emacs -nw) which should just bring it up "normal" on the xterm window you have open. Good luck. Fred
thomas%spline.uucp@utah-gr.UUCP (Spencer W. Thomas) (03/19/87)
Well, I start emacs from a menu item that says
emacs: !"emacs &"
However, I do have a little setup. I run X by "xinit ~/.xstart",
where .xstart includes the lines
#! /bin/sh
TERM=xterm
export TERM
...
uwm 2>&1 >/dev/null &
...
It is the "TERM=xterm" in the environment that makes emacs start
happily and open a window.
If you started uwm from an xterm window, then it should all work fine.
=Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@cs.utah.edu)mayer@hplabsc.UUCP (Niels Mayer) (03/19/87)
In article <1024@theory.cs.cmu.edu> tsf@theory.cs.cmu.edu (Timothy Freeman) writes: > !"xterm =10x10-1000-1000 -e emacs -w =143x68+0+0&" Why start it from an offscreen xterm at all? The significant information that'll pass down to gnuemacs is the value of $TERM.... So On my HP9000/300 (HPUX), I call a script (xgnu) from my .uwmrc menu entry that does the trick: #!/bin/sh # set TERM so that subprograms (like mh's scan) don't assume I'm using a 9836 TERM=xterms export TERM exec gnuemacs -i -fg Green -bg Sienna -bd Black -cr White $* -- Niels.
rlk@athena.mit.edu (Robert L. Krawitz) (03/20/87)
In article <foo@bar.UUCP> various people write:
]
]Why start it from an offscreen xterm at all? The significant information
]that'll pass down to gnuemacs is the value of $TERM.... So On my
]HP9000/300 (HPUX), I call a script (xgnu) from my .uwmrc menu entry that
]does the trick:
]
]#!/bin/sh
]# set TERM so that subprograms (like mh's scan) don't assume I'm using a 9836
]TERM=xterms
]export TERM
]exec gnuemacs -i -fg Green -bg Sienna -bd Black -cr White $*
]
]-- Niels.
Version 17 emacs did indeed look at the TERM variable to decide
whether or not to start up under X. This behavior having been
declared bogus, Version 18 relies on the DISPLAY variable.
Later local versions of 17 (i. e. at Athena) had various intermediate
stages of workingness (e. g. -d would force use of X) but I don't
think any of these hacks ever made it out to the world. V18 does do
the right thing however.
Robert^Zmayer@hplabsc.UUCP (03/20/87)
In article <349@bacchus.MIT.EDU> rlk@athena.MIT.EDU writes: > [... a bunch of stuff about "setenv TERM xterm" ...] > V18 does do the right thing however. Except that it doesn't set the environment $TERM based on the size of the initial startup screen. So if your login console $TERM is set for some 132 column screen, subprograms run by gnuemacs will format their outputs for 132 column displays... A good example of this is the mh scan program for mhe: the mail folder browser will end up presenting wrapped 132 column lines if you start gnuemacs as an 80x24 X window. Perhaps gnuemacs should explicitly set TERM to the correct width before executing programs in subshells? MHE should probably set the screenwidth in $TERM before calling scan. -- Niels.
rlk@bacchus.UUCP (03/21/87)
In article <1462@hplabsc.UUCP> mayer@hplabsc.UUCP (Niels Mayer) writes:
]Perhaps gnuemacs should explicitly set TERM to the correct width
]before executing programs in subshells? MHE should probably set
]the screenwidth in $TERM before calling scan.
You mean TERMCAP rather than TERM (probably TERM should be set to
something like 'emacs', just so programs that like to look up
terminals on their own can't find anything that is wrong). This is an
interesting point.
It's not exclusively an X problem, although it's more likely to be a
problem under a window system than otherwise. Conceivably, whenever
the size of the shell buffer changes, emacs could send a SIGWINCH to
the shell (this is a 4.3BSD-ism, so other folks will be out of luck).
Robert^Zpinkas@mipos3.UUCP (03/25/87)
References:
[Sorry if you've already seen this, but I'm not sure that it made it out.]
I recently installed emacs on my Microvax/GPX, running Ultrix 1.2 and ran
into some problems. In version 18.38 there is a new file called xmenu.c,
which makes reference to a few items that are not defined in ant of the .h
files it includes. (Or in any file under /usr/include on my system.) The
items are:
XM_FAILURE
XM_SUCCESS
XM_IA_SELECT
XM_NO_SELECT
XMenuCreate()
From the context I have deduced that XMenuCreate() should be declared as
follows:
XMenu *XMenuCreate();
If anyone could confirm/deny the above, and supply me with the values
for the four constants, I would be eternally grateful. Any help would be
appreciated.
-Israel
---------------------------------------------------------------------------
Standard disclaimers apply.
--
User (n.): A programmer who will believe anything you tell him.
----------------------------------------------------------------------
UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!pinkas
ARPA: pinkas%mipos3.intel.com@relay.cs.net
CSNET: pinkas%mipos3.intel.comrlk@bacchus.UUCP (03/25/87)
In article <565@mipos3.UUCP> pinkas@mipos3.UUCP (Israel Pinkas) writes:
][Sorry if you've already seen this, but I'm not sure that it made it out.]
]
]I recently installed emacs on my Microvax/GPX, running Ultrix 1.2 and ran
]into some problems. In version 18.38 there is a new file called xmenu.c,
]which makes reference to a few items that are not defined in ant of the .h
]files it includes. (Or in any file under /usr/include on my system.) The
]items are:
]
]If anyone could confirm/deny the above, and supply me with the values
]for the four constants, I would be eternally grateful. Any help would be
]appreciated.
]
From /usr/include/X/XMenu.h:
#define XM_FAILURE -1
#define XM_SUCCESS 1
#define XM_NO_SELECT 2
#define XM_IA_SELECT 3
XMenu *XMenuCreate();
What X distribution do you have? If you have XV10R3, you should not
be using XMenu in emacs because of a bug in the XMenu package (I
believe the makefile for 18.41 has a conditional for this, USE_X_MENU
or something like that). If you have XV10R4, then you can use X
menus.
Robert^Z