Xref: utzoo gnu.emacs:3431 comp.windows.x:25392 comp.sys.hp:5827 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!shelby!rutgers!cunixf.cc.columbia.edu!cs.columbia.edu!tim From: tim@cs.columbia.edu (Timothy Jones) Newsgroups: gnu.emacs,comp.windows.x,comp.sys.hp Subject: problems with gnu emacs 18.55 on HP 9000/300 Message-ID: Date: 6 Aug 90 18:49:44 GMT Sender: tim@cs.columbia.edu (Timothy Jones) Organization: Columbia University Department of Computer Science Lines: 38 We're experiencing some weird problems with gnu emacs 18.55 and X on our HP 9000 series 300 machines that hopefully someone can help me solve. Whenever emacs is started with X switches, like -font or -geometry, a new buffer is created under the name of the argument to that switch. For example, if I run it with "emacs -font 9x15", emacs pops up in the correct font, but now there's a buffer named "9x15"! Also, emacs doesn't seem to respond to mouse button clicks for setting the cursor position anymore. These problems reared their ugly heads a couple of weeks ago (everything had been working fine before then). The strange part is, we haven't made any changes anything that I can think of which might cause this. No new emacs, no new X stuff, no new anything. It's quite perplexing. If I run emacs without X switches, everything seems to work fine. For example, "emacs -u " pops up a new emacs running 's .emacs, and there's no buffer named . If I combine this switch with another, X related, one, the problem comes back again, which leads me to think that the X command-line parser isn't removing things from argv correctly. These problems occur both on machines running HP-UX 6.5 and 7.0, and using both the X11R3 server supplied with HP-UX and the new R4 server recently released by HP. Has anyone experienced similar behavior, or can you think of something I'm not? Please email responses. Thanks in advance, Tim -- Timothy Jones tim@cs.columbia.edu Department of Computer Science ...!rutgers!cs.columbia.edu!tim Columbia University tim%cs.columbia.edu@cuvmb.bitnet